Кэш страниц в PHP, который обрабатывает параллелизм?

Question

Я читал предыдущие ответы здесь о кешировании в PHP и статьях, на которые они ссылаются. Я проверил часто рекомендуемые Pear Cache_Light , QuickCache и WordPress Super Cache. (Извините - по-видимому, мне разрешено давать гиперссылку только один раз.)

Либо никто не занимается проблемами параллелизма, либо никто явно не упоминает, что они делают в своей документации.

Кто-нибудь может указать мне направление кеша страниц PHP, который обрабатывает параллелизм?

Это на общем хосте, поэтому кеширование в memcache и opcode, к сожалению, не вариант. Я не использую шаблонизатор и хотел бы избежать зависимости от него. Подход WP Super Cache предпочтителен - то есть хранение статических файлов в wwwroot, чтобы Apache обслуживал их, но не является обязательным требованием.

Спасибо!

P.S. Примеры вещей, которые должны обрабатываться автоматически:

1. Apache / PHP-кеш находится в середине чтения кэшированного файла. Кэшированный файл устарел и предпринимается попытка удаления.
2. Кэшированный файл был удален, поскольку он устарел. Приходит запрос на этот файл, и файл находится в процессе воссоздания. Во время этого поступает еще один запрос файла.

Answer 1

Кажется, что PEAR :: Cache_Lite имеет некоторую защиту для решения проблем параллелизма.
Если вы посмотрите руководство по constructor Cache_Lite::Cache_Lite, у вас есть следующие варианты:

fileLocking включить / отключить блокировку файлов. Может избежать повреждения кэша при плохом обстоятельства.

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

readControl включить / отключить контроль чтения. Если включено, управляющий ключ встраивается в файл кэша и этот ключ сравнивается с рассчитанным после чтение

readControlType Тип контроля чтения (только если контроль чтения включен). Должно быть "MD5" (для хеш-контроля MD5 (лучше, но самый медленный)), 'crc32' (для хэша crc32 контроль (чуть менее безопасно, но быстрее)) или 'strlen' (для длины только тест (самый быстрый))

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

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

Похоже, что он также поддерживает некоторую защиту - тот же самый набор вещей, который Cache_Lite уже дал вам (так что я не буду копировать-вставлять второй раз)

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

В любом случае, я, вероятно, не стал бы искать дальше того, что предлагают эти буксирные фреймворки: этого уже, вероятно, более чем достаточно для нужд вашего приложения: -)

(Я никогда не видел, чтобы какой-то механизм кэширования был «более безопасным», чем те, которые позволяют вам делать ... И я никогда не сталкивался с какой-то катастрофической проблемой параллелизма такого рода ... За 3 года PHP-разработки)

В любом случае: веселиться!

Answer 2

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

Имеет элегантную и понятную структуру: интерфейсы -> адаптеры -> классы для легкого расширения. На странице github я подробно объясняю, в чем проблема с хлопками и как ее решает библиотека.

Проверьте это здесь: https://github.com/tztztztz/php-no-slam-cache

Answer 3

Я хотел бы изменить один из существующих кэшей. Кэш Zend Framework должен быть в состоянии сделать свое дело. Если нет, я бы это изменил.

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

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

Jacob

Answer 4

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

Answer 5

Предполагается журналируемая файловая система (большинство файловых систем Linux и NTFS) - тогда файл не должен рассматриваться как «созданный», пока процесс закрывает файл Это должно отображаться как несуществующий файл!

Нет, он виден, как только он создан, его нужно заблокировать. Переименовать атомно, хотя. Таким образом, вы можете открыть (), написать (), закрыть (), переименовать (), но это не помешает повторному созданию одного и того же элемента кеша дважды одновременно.

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

Если он не заблокирован, файл будет заполнен наполовину, или два процесса попытаются создать один и тот же файл одновременно, давая «интересные» результаты.

Answer 6

1. Обычно в Linux файл остается «открытым» для чтения, даже если он «удален», пока процесс не закроет файл. Это что-то встроенное в систему, и оно может иногда вызывать огромные расхождения в размерах использования диска (удаление файла 3G, пока он все еще «открыт», будет означать, что он все еще размещен на диске в процессе использования, пока процесс не закроет его) Я не уверен, верно ли то же самое в Linux.
2. Предполагая журналируемую файловую систему (большинство файловых систем Linux и NTFS) - тогда файл не должен рассматриваться как «созданный», пока процесс не закроет файл. Это должно отображаться как несуществующий файл!