Кеширование страниц сайта

Deni,

От двойного кэширования отказывайтесь. При кэшировании вырезать пробелы и комменты - хорошо, но зажимать в архив - особенно если потом каждый раз приходится пережимать - плохая идея. Место экономится, но процессор кушается неплохо.

Про CNStats, не очень помним эту систему, но мы бы вставляли её html кодом, а не include. Кажется там есть такой вариант, если нет - надо его дописать. Заодно будет очень хороший бонус, что грузящая статистика не будет "мешать" работе основного скрипта.

По поводу инклудов - можно попробовать использовать ssi для инклудов. Будет все-таки меньше кода обрабатываться php интерпретатором, а это время и нагрузка.

По поводу указания "что кэшировать" комментариями и кэширования. Не совсем поняли как можно в "сайте" комментировать подгрузку "динамических частей". В коде сайта? Или как? Можно вот этот момент пояснить?

Но тем не менее по поводу кэширования. Надо просто бить страницу на блоки и указывать какие когда надо кэшировать. Допустим событие редактирование новости - пусть стирает кэш всех "связанных новостей" и сам кэш новости. Можно указывать в комментарии "тип триггера" обновления кэша: мы например используем 3 варианта - по времени (истекло - обновили), по событию редактирования (глобальный обработчик как правило можно привязать к имени исполняемого модуля и POST запросу), по вероятности (допустим с вероятностью 1/100 обновляется кэш).

То что заголовки страниц определяются в 50% случаев - надо проверить правильно ли удаляются пробелы и комментарии.

То что страница из кэша отдается медленнее чем страница из БД это немного грустно, но надо учесть что

а) Более высокое время генерации страницы не означает более высокую нагрузку

б) Возможно БД шустрее ФС (например если БД на отдельном сервере мощном, а ФС на перегруженном слабом)

в) Файл это не некий "сферический конь в вакууме". Обращение к файлу занимает время. И если допустим идет 4 инклуда файлов кэша плюс все равно идет пара запросов в БД, то это может реально оказаться дольше по времени, чем 6 запросов в БД. Наличие кэширования хорошо, но настройка кэширования не менее важно.

г) "Паразитное сжатие" на время генерации влияет.

Именно так, для экономии времени заказчик пишет ТЗ, а программист без вопросов (с уточнениями по поводу непонятных моментов) пишет то, что в нём указано. ИМХО это совершенно верно т.к. про составление ТЗ программисту никто не говорил и он совершенно справедливо на мой взгляд не вмешивается с советами т.к. чтобы адекватно советовать нужно анализировать сайт, а тратить на это своё время просто так никто не будет

Вариант со вставкой без инклуда не подходит т.к. этот тип счётчика (PNG или GIF) не считает роботов, а их подсчёт важен Дмитрию

В шаблоне движка ставятся коментарии определённого формата

<!-- begin:folder/include.php --> текст, который будет вырезан <!-- end:folder/include.php -->

при создании файла кеша эти коментарии заменяются на конструкцию <?php include "/www/domain/folder/include.php";?> которая обрабатывается при каждом обращении к странице кеша. При этом то, что находится внутри коментария? вырезается (сделано чтобы заменить случайные статьи, генерируемые движком, на те, что генерируются инклудом)

Роботов можно выдирать из apache лога. Если они нужны в общей статистике, то можно раз в сутки парсить лог и вставлять в CNStats. Впрочем это не должно быть критично и к кэшу отношение имеет лишь косвенное.

Согласны с таким решением, единственно что инклудить тоже наверное можно не каждый раз - тут надо бы AI легкий добавить, такой же как к кэшу например. И от архивации для хранения в таком варианте надо отказываться, потому что интерпретатор архив не поймет конечно.

Счётчик и ещё один инклуд должны срабатывать при каждом просмотре страницы.. так что приходится инклудить их каждый раз без исключений. По поводу архивации согласен, получается, что сжимать нужно два раза, а на это тратиться больше времени чем выигрывается (выигрываются там вообще копейки т.к. объём сжимаемого контента в среднем 20Kb)

Насколько затратная сама вставка инклуда вообще?

т.е. обращение к файлу и его открытие инклудом много процессорного времени требует?

если инклудиться к пример 10 файлов - как это скажется на быстродействии?

можно ли как-то расчитать время за которое сервер выполняет данные операции?