Агрессивное кэширование сгенерированного содержимого при сохранении аутентификационной информации

Question

Я использую Symfony 2 для генерации своих страниц из данных в базе данных MySQL.Для большей части контента пользователи должны проходить аутентификацию, но сам контент не часто меняется и не требует индивидуальной настройки для пользователей.Итак, какова хорошая стратегия кэширования, позволяющая избегать вызовов базы данных при сохранении проверки подлинности?

Answer 1

Проще говоря, используйте Memcache для кэширования набора результатов SQL в течение длительного периода времени.

Answer 2

Я решил это с помощью Zend_Cache внутри кэшируемых действий для сохранения результата визуализации шаблона. Затем я создаю новый Response объект из кэшированного содержимого. Если кеш пуст, я генерирую контент.

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

Answer 3

Если вы используете Symfony2, вы используете Doctrine2, если вы используете Doctrine2, кэширование должно быть включено по умолчанию.

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

Не используйте Doctrine без метаданных и кэша запросов!Доктрина высоко оптимизирована для работы с кешами.Основными частями в Doctrine, которые оптимизированы для кэширования, являются информация отображения метаданных с кешем метаданных и преобразования DQL в SQL с кешем запросов.Эти 2 кэша требуют только абсолютного минимума памяти, но они значительно улучшают производительность Doctrine во время выполнения.Рекомендуемый драйвер кеша для использования с Doctrine - APC.APC предоставляет вам кэш-код операции (который настоятельно рекомендуется в любом случае) и очень быстрое хранение в кэш-памяти в памяти, которое вы можете использовать для метаданных и кешей запросов

Answer 4

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

Создайте несколько наборов страниц, один для еще не авторизованных пользователей (давайтев корне сайта) и другие для аутентифицированных пользователей, которые должны видеть один и тот же контент (скажем, два или более должны видеть один и тот же контент при аутентификации, тогда мы создадим только один набор для всехиз них), и поместите его в каталог под root.Затем создайте простые файлы .htaccess / .htpasswd для каждого такого каталога «только для авторизации», и тогда проблема веб-сервера будет не в вашем скрипте.

Надеюсь, вы поняли идею.Сказать это нечетко, но легко реализовать.

Пример : допустим, вы хотите, чтобы только аутентифицированные пользователи могли видеть страницу '/topsecret.html' на сайте.Создайте dir (/ authed), установите для него HTTP-auth и поместите ваш topsecret.html в dir (так что это будет «/authed/topsecret.html»).Теперь отредактируйте файл «/topsecret.html» и просто замените его основное содержание ссылкой «извините, пожалуйста, подтвердите себя», которая будет указывать на «/authed/topsecret.html».

Answer 5

Похоже, что у вас есть много вариантов для кэширования с помощью симфонии http://www.symfony -project.org / book / 1_2 / 12-Caching (не для 2, но мое предположение не так много изменилось ).

Вы можете поместить свои тяжелые операторы sql в собственный скрипт и включить кэширование для этого скрипта

list:
  enabled:     on
  with_layout: false   # Default value
  lifetime:    86400   # Default value

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

$this->getResponse()->addCacheControlHttpHeader('max_age=1200'); // in seconds - less than 1 year seconds

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