В чем разница между Zend_Cache_Frontend_Capture и Zend_Cache_Frontend_Page
Может кто-нибудь объяснить разницу между этими двумя интерфейсами Zend_Cache_Frontend_Capture и Zend_Cache_Frontend_Page?
Capture используется по умолчанию для кэширования страниц... странно то, что он делает id с помощью get-переменных, но нет никаких параметров для установки make_id_with_get_variables, как в случае с внешним интерфейсом страницы....
может кто-нибудь объяснить это?
1 ответ
Вот мое усилие объяснить разницу между ними.
Для начала давайте посмотрим на Zend_Cache_Frontend_Capture. Ссылка утверждает, что этот класс предназначен для работы только с Zend_Cache_Backend_Static,
Вы бы использовали Zend_Cache_Frontend_Capture кэшировать целые страницы, которые не имеют отношения к пользователю, обращающемуся к сайту. Этот интерфейс используется, когда у вас есть статические данные (которые могут время от времени изменяться), которые не имеют отношения к текущему пользователю, то есть они одинаковы для всех пользователей (например, RSS-канал или динамически создаваемый файл JavaScript).
Посмотрев дальше в Zend_Cache_Backend_Static, вы увидите, что этот бэкэнд немного особенный. Это требует правил в вашем .htaccess файл, чтобы помочь с обслуживанием кеша. Как только вы что-то кэшировали Frontend_Capture/Backend_StaticPHP и Zend Framework НЕ используются для обслуживания кэшированных данных. Apache видит, что файл кеша существует на основе вашего.htaccess и передает содержимое напрямую пользователю, не вызывая PHP.
Zend_Cache_Frontend_Page с другой стороны, работает по-другому. С его помощью вы можете кэшировать контент не только на основе URI запроса, но и на основе информации в параметрах cookie, сеанса, GET или POST. По умолчанию кэширование на основе файлов cookie, сеанса, получения и публикации отключено, поэтому для того, чтобы это могло повлиять на пользователя, вошедшего на ваш сайт, вы должны указать кешу, есть ли какие-либо страницы, которые вы хотите кэшировать на основе этого. Информация.
После того, как я создаю кеш и сообщаю ему, что я хочу кешировать на основе куки и сеанса, я могу теперь кешировать динамически генерируемую страницу, специфичную для одного пользователя. Так что, если человек А получает доступ /accounts/, страница может быть кэширована для этого конкретного пользователя, содержащая список его учетных записей, которые были извлечены из базы данных. Теперь, когда человек B получает доступ /accounts/они не видят кэш для лица А, поэтому страница для них теперь кэшируется отдельно с информацией о каждом соответствующем пользователе в их собственном кэше.
В итоге:
Используйте интерфейс Capture, если у вас есть данные, которые вы можете кэшировать, то же самое для ВСЕХ пользователей. Это будет кэш с более высокой производительностью, так как PHP и ZF не нужны после кэширования страницы. Недостатком является необходимость добавления правил кэширования в.htaccess.
Используйте внешний интерфейс страницы, если вы хотите кэшировать страницы с динамическим выводом, основанным не только на URI запроса, но и на файлах cookie, данных сеанса или параметрах get/post.
Надеюсь, что это ясно и поможет вам понять различия.
РЕДАКТИРОВАТЬ: Я считаю, что я вижу, в чем проблема, не уверен, если это классифицируется как ошибка или нет, хотя.
Zend_Controller_Action_Helper_Cache::preDispatch() генерирует идентификатор кэша на основе URI запроса (который включает строку запроса). Поскольку тикер jQuery добавляет строку запроса к URL-адресу, вы кэшируете одну копию канала для каждого URI запроса. (Ищите $reqUri в вышеупомянутом методе класса).
Я вижу несколько вариантов: 1) посмотреть, можно ли заставить тикер не добавлять строку запроса (по крайней мере для этого конкретного URL) или 2) вручную запустить кэш захвата и передать свой собственный идентификатор, вместо того, чтобы позволить помощнику кэша сгенерировал его на основе URI запроса.