Как реализовать кэш PHP / HTML

Question

Я прочитал несколько руководств по внедрению системы кэширования php (мой сайт имеет пользовательскую кодировку, довольно большой объем запросов и растет), в том числе: http://www.snipe.net/2009/03/quick-and-dirty-php-caching/

Я понимаю их полностью, но есть определенные части страницы, которые я не могу кэшировать, как лучше это сделать?

Answer 1

кэширование полезно, если вы много читаете, но редко обновляете. чем чаще изменяются данные в базе данных, тем сложнее становится система кеширования. Кэширование добавляет некоторую сложность вашей кодовой базе, с которой может быть трудно справиться. и это может даже замедлить ваш сайт в худшем случае.

самый важный вопрос:
когда вам нужно аннулировать ваш кеш? когда это становится несвежим? в большинстве случаев, если запрос к базе данных возвращает строки, отличные от того, когда вы кэшировали эту страницу. но откуда ты это знаешь? Вы не можете (возможно, есть способ, но я не могу думать ни о каком банкомате), потому что, чтобы проверить это, вам, вероятно, придется запросить результат для сравнения.

что вы можете сделать:

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

2. очистить кэшированные элементы после того, как что-то произойдет
   это работает, только если изменения не должны отражаться мгновенно (например, не имеет значения, если в течение некоторого времени есть неверные данные). в этом случае вы можете просто очистить кэш для определенного элемента, если он старше X минут или произошел просмотр страниц более Y.

3. очистить только соответствующие части
   здесь вы должны выяснить, какие части кэша затрагиваются при обновлении базы данных. Если все сделано правильно, изменения отражаются мгновенно, а производительность улучшается.

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

изменения внесены: админ-панель (crud для записей) и комментарии

если запись редактируется или удаляется, вы должны очистить кеш для:

• титульная страница, если запись была новой
• соответствующая страница архива, если запись была старой
• страница сведений для записи

если кто-то комментирует, вам просто нужно очистить страницу сведений, но только если количество комментариев не отображается в индексе или архиве. в противном случае, то же самое, что и entry-crud.

если что-то изменилось, весь кэш должен быть очищен (плохо!)

Теперь давайте подумаем о entry-crud и архиве. если архив имеет тип «одна страница в месяц», очистите месяц, к которому относится запись. но если в архиве есть записи 1-10, 11-20, 21-30, ... чаще всего нужно перестроить весь архив-кеш.

и так далее ...

некоторые проблемы:

• Если вы не правильно идентифицируете все затронутые фрагменты, это может привести к устареванию данных и / или (не) мертвым ссылкам.

• если обновления происходят слишком часто, создание кеша - дополнительная работа, потому что при следующем просмотре страницы кеш, скорее всего, снова устареет и его все равно придется перестраивать.

• некоторые части страницы непригодны для кэширования, например (пользовательская) функция поиска. если кеш работает где-то еще, все быстро и замечательно, но поиск по-прежнему ужасно медленный.

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

мой совет:

• оптимизировать вашу базу данных. ключи и конфиг ок? возможно это работает без кеширования.

• оптимизировать ваши запросы. "Объясни выбор"!

• только части кеша страницы - дорогие. заполните небольшие, дешевые изменения с помощью str_replace и заполнителей

• если все работает, используйте вместо файлов apc или memcached (файлы обычно работают отлично, но apc / memc работают быстрее). Вы также можете использовать свою базу данных для кэширования базы данных, часто это прекрасно работает!

• Вы строите ленивую или энергичную систему кеширования? «Ленивый» означает: создать кэш при первом запросе страницы, «нетерпеливый» означает: сразу после обновления.

Мех, у меня нет никаких реальных советов для вас. слишком много зависит от проблемы:)

обновление

есть запрос на запись в блоге с ключом 256. он показывает запись в блоге, комментарии и кто в данный момент вошел в систему. Это дорогой запрос на запись и комментарии, а также форматирование всего текста и всего. зарегистрированный в данный момент пользователь находится в сеансе.

Сначала создайте уникальный ключ для части, которую вы хотите кэшировать. в этом случае ключ кеша, вероятно, является идентификатором базы данных записи (с некоторым префиксом и постфиксом).

Итак, кэшированный файл должен иметь имя cache/blogentry_256.tmp. проверьте, существует ли этот файл.

1. если его не существует, выполните все дорогостоящие запросы и форматирование, оставьте заполнитель (например, {username}) там, где должно быть имя текущего пользователя, и сохраните результат в cache/blogentry_256.tmp. будьте осторожны, чтобы не записывать в этот файл какие-либо данные, которые не должны отображаться для всех или изменяться при каждом запросе.

2. Теперь прочитайте файл (или повторно используйте данные из 1) и str_relace имя пользователя в заполнитель. echo результат.

если запись изменяется или кто-то комментирует, вы должны удалить кеш-файл с идентификатором записи.

это ленивое кеширование - кеш строится только если пользователь запрашивает страницу. будьте осторожны - если пользователь вводит {username} в комментарий, он тоже там вставляется! это означает, что вы должны выйти из кэшированных данных и удалить их после str_replacing. эта техника работает и с memcached или apc.

проблемы: вы должны построить свой дизайн вокруг этого решения о кэшировании. например если вы хотите отобразить «комментарий, опубликованный 5 минут назад» вместо «комментарий, добавленный 6 мая, 15:42», то у вас проблемы.

Answer 2

Почему вы не можете их кешировать? Если это происходит из-за того, что они меняются очень быстро, то вам, вероятно, лучше попытаться уменьшить затраты на поиск и рендеринг.

Если содержимое зависит от пользователя, вы можете предложить разные кэшированные версии для каждого пользователя. Если вы используете кеш объекта, например, включите идентификатор пользователя или другое уникальное значение в ключ кеша. Если вы используете более общий кеш уровня HTTP, такой как Squid, тогда вы можете установить заголовок Vary, например, Vary: Cookie, в результате чего прокси-сервер дважды проверит, кому он передает контент.

Вы по-прежнему должны указывать кэшам и прокси-серверам не хранить конфиденциальную информацию в общедоступных кэшах.

Answer 3

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

Кроме того, как и при любой оптимизации, убедитесь, что вы измеряете, прежде чем что-то настраивать. Это гарантирует, что 1) вы на самом деле улучшаете вещи, а не делаете их хуже, и 2) вы сосредотачиваетесь на вещах, которые важны, а не на чем-либо другом.

Answer 4

Вот мой совет: создайте объект или функцию, которая позволит вам кэшировать «раздел» на основе его имени. Таким образом, вы можете кэшировать часть вашей страницы и включать раздел рендеринга в блок if. Я хэшировал входящий текст и использовал его в качестве имени файла в './cache' и возвращал логическое значение того, нужна ли регенерация; для этого вам, очевидно, потребуется буферизация вывода.

Это даст вам структуру кэша,

if(Cache::cached('index-recent-articles', 5 /* minutes */)) {
   Cache::start();
   echo 'stuff here';
   Cache::stop('index-recent-articles');
} // And if Cache::cached could echo the cached HTML when the result is false...
  // then this is a tidy else-less bit of code.

Я не знаю, является ли это оптимальным, решение на основе сервера, такое как memcache, было бы лучше, но концепция должна помочь вам. Очевидно, как вы управляете кэшем, будь то файлы, база данных или расширение, зависит от вас.

Edit:

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

abstract class Cache {
  const path = 'cache/';
  static function start()  { ob_start(); }
  static function end($id, $text = null) {
    $filename = sprintf('%s%u', Cache::path, crc32($id));
    file_put_contents($filename, $text === null ? ob_get_clean() : $text);
  }
  static function cached($id, $minutes = 5) {
    $filename = sprintf('%s%u', Cache::path, crc32($id));
    $time = $minutes * 60;
    if(time() - filemtime($filename) > $time) {
      return true;
    } else {
      echo file_get_contents($filename);
      return false;
    }
  }
}