Чаще всего это проекты созданные на редакции Старт и реже Стандарт и Малый бизнес.
Или это могут быть целые разделы сайта на других редакциях.
Однажды созданные разделы или материалы на таких сайтах могут не обновляться месяцами.
Много таких проектов создают оптимизаторы.
И хоть в режиме Автокэширования наш продукт не выполняет ни одного запроса к базе данных и отдает страницы максимально быстро, все же виртуальный хостинг замедляет выдачу страниц просто из за самого факта подключения PHP и из-за высокой загруженности дисковых подсистем.
И всегда хочется минимизировать расходы для хостинга для самых простых и легких проектов.
В рамках работ над Контроллером сайтов нами разработан новый тип кеширования, который получил название "HTML кеш".
[spoiler]
Эта технология вошла во все редакции продукта начиная с версии 6.5.8 главного модуля.
Располагается на вкладке "Настройки"-"Настройки продукта"-"Автокеширование"-"HTML кеш"
[spoiler]
На решениях с Контроллером мы используем эту технологию и отдаем эти страницы через NGINX за счет чего обеспечивается огромный ресурсный рост для редко изменяющихся сайтов или страниц. Например наш тестовый сайт обрабатывает 70 запросов в секунду, а с HTML кещ через NGINX уже 1200-1600 страниц в секунду.
В целом, я считаю, что HTML кеширование станет технологией повседневного использования для очень многих небольших проектов. А в сочетании с Контроллером сайтов вообще станет в руках наших партнеров ядерным оружием
Технология проста в эксплуатации, не требует от пользователя отслеживать изменения, защищает дисковой квотой от накрутки данных и само-восстанавливает работоспособность при превышении квоты или изменении данных.
Как только пользователь авторизуется в продукте, он уже работает с сайтом без кеширования, как с обычным продуктом.
Технология HTML кеширования работает в нашем автоматическом режиме AJAX с компонентами 2.0.
Так что это тоже будет удобно использовать на проектах.
Есть и ограничения в использовании. В частности, мы не советуем включать HTML кеш (или включать обдуманно по разделам) для редакций, которые содержат веб-аналитику и модуль рекламы.
Приведу фрагмент описания технологии:
Механизм HTML-кеширования лучше всего включить на какой-нибудь редко изменяющийся раздел с регулярным посещением анонимных посетителей, так как при включенном HTML-кешировании происходят следующие процессы:
* механизмом HTML-кеша обрабатываются только страницы, не указанные в маске исключения и указанные в маске включения;
* если на такие страницы заходит не авторизованный пользователь, то выполняется проверка существования файла кеша и если таковой найден, то выдается страница из кеша, не задействуя никакие модули продукта; например, не будет работать модуль статистики (не засчитаются хиты этого пользователя), модуль рекламы, главный и другие модули;
* при этом, если на момент включения кеша был установлен модуль компрессии, то страница будет отдаваться в сжатом виде;
* если страница в кеше не найдена, то код исполняется в обычном режиме; когда страница полностью сформирована, ее копия сохраняется в HTML-кеш;
Oчистка кеша:
* если сохраняемый объем приводит к превышению дисковой квоты кеша, то кеш полностью очищается;
* так же полная очистка кеша происходит при любом изменении данных в административной части системы;
* если в публичной части сайта происходит POST данных (например, добавление комментария или голосование), то сбрасывается соответствующая часть кеша;
Необходимо отметить, что для неавторизованных пользователей происходит удаление сессии (например, если неавторизованный пользователь перейдет в закешированную часть сайта, то все данные его сессии будут удалены).
Из всего выше сказанного следует, что:
* не ведется учет статистики;
* модуль рекламы будет работать только в момент создания кеша (это не относится к внешней динамической рекламе (Begun и пр.);
* например, для неавторизованных пользователей результаты сравнения товаров не будут сохранены (так как его данные хранятся в сессии, которой "нет");
* необходимо обязательно задать дисковую квоту в настройках модуля HTML кещ во избежание DOS-атаки по дисковому пространству;
* после включения механизма HTML-кеширования необходимо проверить весь функционал раздела, к которому применен кеш (например, может не сработать публикация комментариев со старыми шаблонами блогов);
Обновления главного модуля 6.5.8 вышло в систему обновлений сегодня.
редакция Старт, 2 простых сайта с разными доменами на одной лицензии, после включения HTML-кеширования получаем на втором сайте некоторую "солянку" из кэша страниц первого сайта.
Для каждого сайта надо создать каталог /bitrix_personal в корне.
Для "не общих" данных (в том числе и кеша).
Все не так просто...
Эта настройка позволяет "разнести" по сайтам бывшие ранее общими такие вещи как:
SetEnv BX_PERSONAL_ROOT "/bitrix_personal
Вы пишите: "Для каждого сайта надо создать каталог /bitrix_personal в корне. Для "не общих" данных (в том числе и кеша)."
Я создал эти папки с правами 755 для обоих сайтов. Я правда заметил, что даже без этих папок, простым добавлением записи в httpd.conf, баг с неправильным отображением шаблона пропал. Эти папки действительно нужны?
Первому или второму?
Предупреждение "Только не надо спешить!" не остановило
Однако все же надо было придумать что-нибудь, что бы позволяло на одном из сайтов html кэш включить, а на другом выключить.
побежал обновлять клиентов.
Проект работает на основе "1С-Битрикс: Управление сайтом 6.5.6".
обидно и непонятно.
Нужно чуть-чуть потерпеть...
терпим... ждем...
неужто в папке rsv лежит больше 200 php-файлов?
или это все-так мод рерайт так странно настроен?
спросил бы в форуме, то там мне почему-то не дает создавать темы
ЧПУ?
Странно, форум доступен всем после регистрации на сайте.
Возможно, что-то изменилось в вашем профиле с последнего активного захода.
ну в крайнем случае вот так
Зачем php-то на конце цеплять?
Однако для своих проектов я делал модуль кеша на файлах который на моем ноуте давал 700 запросов в секунду. На php.
Но. Единственное тонкое место - удаление файлов кеша когда припрет. От него пришлось отказаться
Потому что несколько тысяч подкаталогов единомоментно мочить - большая проблема.
Благодаря flock на файлах внутри подподподкаталогов и чекпойнтов проблему решил. Просто делали файлики неактуальными )
>* если сохраняемый объем приводит к превышению дисковой квоты кеша, то кеш полностью очищается;
>* так же полная очистка кеша происходит при любом изменении данных в административной части системы;
Вопрос а как сброс проводите?
По крону - перемещение плюс рекурсивное удаление? Или во время работы скриптов?
+учет размера кеша?
>Из всего выше сказанного следует, что:
Последствия в такой полустатической системе неизбежны да... Тут придется баннеры и прочее отдать внешним севисам.
в каталоге товаров добавлять товар не перегружая страницу и показать на той же странице корзину во всплывающем псевдоокне.
Задача решена с использование ajax (JQERY). На ссылку купить поставил событие onclick которое отрывает всплывающее окошко. Окошко подгружает страницу и отправляет get запросом параметы. Все работает, но время от времени полчучается такая ситуация: товар добавляется, а во всплывающем окне пишется что корзина пуста или если она была не пуста, то она показывает устаревшие данные. Подчеркну что это случается не постоянно а в соотношении 1:3 (те 1 из 3-4 попыток неудавшаяся).
Вот код страницы для всплывающей корзины:
<?define('STOP_STATISTICS', true)?> <?require_once($_SERVER["DOCUMENT_ROOT"]."/bitrix/modules/main/include/prolog.php"); //$APPLICATION->SetTitle("Title"); ?> <?BXClearCache(true, 'bitrix:sale.basket.basket')?> <?$GLOBALS['APPLICATION']->RestartBuffer(); if (CModule::IncludeModule("sale") && CModule::IncludeModule("catalog")) { if (($_REQUEST['action'] == "ADD2BASKET" || $_REQUEST['action'] == "BUY") && IntVal($_REQUEST['id'])>0) { Add2BasketByProductID( $_REQUEST['id'], 1, array() ); } } ?><?$APPLICATION->IncludeComponent( "bitrix:sale.basket.basket", "minibasket", Array( "PATH_TO_ORDER" => "/personal/order.php", "HIDE_COUPON" => "Y", "COLUMNS_LIST" => array("NAME","PRICE","TYPE","DISCOUNT","QUANTITY","DELETE","DELAY","WEIGHT"), "QUANTITY_FLOAT" => "N", "PRICE_VAT_SHOW_VALUE" => "N", "COUNT_DISCOUNT_4_ALL_QUANTITY" => "N", "SET_TITLE" => "Y" ), false );?><br> <input type="button" value="Продолжить покупки" class="jqmClose" onc lick="$('#ex2').jqmHide()"> <?die()?>Все попытки отключить кеширование не помогают, проверял даже заголовки ответа сервера - браузер кешировать не должен. Также на всякий случай в ajax запросе поставил параметры "синхронный запрос" и "не использовать кеширование". Также не помогает отправка параметра "?clear_cache=Y". HTML кеширование не включено.
ЧТО ЕЩЕ МОЖЕТЕ ПРЕДЛОЖИТЬ?
CSaleBasket::Init(); $arRes = array(); $db_res = CSaleBasket::GetList(($by="NAME"), ($order="ASC"), array("FUSER_ID"=>$_SESSION["SALE_USER_ID"], "LID"=>SITE_ID, "ORDER_ID"=>"NULL")); while ($res = $db_res->GetNext()) { if (strlen($res["CALLBACK_FUNC"])>0) { CSaleBasket::UpdatePrice($res["ID"], $res["CALLBACK_FUNC"], $res["MODULE"], $res["PRODUCT_ID"], $res["QUANTITY"]); } }перед вызовом компонента корзины (bitrix:sale.basket.basket, именно с ним была проблема, за sale.basket.basket.line и sale.basket.basket.small таких багов не замечал)