Кэширование и просмотр страниц с помощью Varnish / ESI и Zend Framework

Question

У меня есть несколько сценариев, которые мне нужно будет рассмотреть через несколько месяцев.Просто задаю вопрос, чтобы я мог обдумать дискуссию.

Я использую Zend Framework для своего стека приложений.Я использую APC для кэширования на сервере (а не в memcache, поскольку, как я полагаю, memcache не приносит мне никакой пользы, даже если мое приложение распределено).

Мое приложение было создано для работы без JavaScript, изатем для поддержки JavaScript я ломаю страницу и отрисовываю дружественную для JavaScript версию.

Если вы анализируете простую страницу, возможно, 80% ее составляют основные функции, которые можно кэшировать для каждого пользователя.Тогда 20% из них настроены для этого пользователя.Например, мне может потребоваться отобразить

• Последние 5 просмотренных элементов
• Избранные элементы

Эти два «виджета» будут характерны для каждого пользователя.Я рассматривал возможность использования ESI для этих компонентов, но потом решил, что наиболее трудоемким аспектом любого / моего приложения Zend Framework является процесс начальной загрузки и отправки.Так что, если мое приложение занимает 80 мс в настоящее время без кэширования.Как 90% относительного времени тратится на загрузку и на подключаемые модули, если бы я использовал ESI для загрузки этих двух «виджетов», то я бы эффективно добавил нагрузку на каждую страницу?Поскольку я буду инициировать еще один запрос 80 мс для каждой кэшированной страницы.

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

Если я ищу максимальную производительность, это кажется лучшим решением?

Answer 1

Вы можете создать второе простое приложение, которое читает из кэша на основе вызова ajax и загружается только в том случае, если информация не была кэширована. затем ответ может быть добавлен в кэш, чтобы дальнейшие вызовы не загружали ваш Zend-проект. это нормальная процедура, но она также требует программирования аннулирования кэша. Вы уже используете APC, который подойдет для этого. очевидно, он не будет работать для последних 5 просмотренных или похожих материалов.

Answer 2

Лак с ESI не поможет вам сократить время загрузки страницы, зная, что 80 мс - это уже хорошо (пользователь не будет иметь никакого значения от 1 до 500 мс ...)

Это поможет вамИзбегайте нагрузки на сервер при больших нагрузках, и это будет работать как с ESI, так и с AJAX.

Если ваш приоритет - максимально быстрое отображение главной страницы, AJAX - лучший способ, так как ESI будет ждатьподзапрос, чтобы ответить перед отправкой всей страницы.

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