Что использовать?

Начнем с построения Front-end системы и определения целей и задач, которые будет решать данная часть двухуровневой архитектуры.

В качестве Front-End сервера можно использовать NGINX, SQUID, OOPS или любой аналогичный продукт.

NGINX представляет собой очень компактный и быстрый веб-сервер (HTTP-сервер). Он потребляет очень мало оперативной памяти, умеет самостоятельно обслуживать статические запросы и выполнять акселерированное проксирование без кэширования статических объектов. Например, если запрашивается графический объект, NGINX самостоятельно выполняет считывание данных с диска и передает файл пользователю.

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

Наилучшие практические результаты получены при использовании NGINX. Но использование кэширующих прокси-серверов также возможно с получением отличных результатов.

Двухуровневая архитектура выставляет перед пользователем Front-end легкий веб или прокси-сервер, который принимает все запросы от пользователей, исполняет все запросы, которые возможно обработать самостоятельно без обращения к Back-End. Если используется NGINX или аналогичный продукт, все статические объекты напрямую считываются с диска и передаются клиенту. Если используется кэширующий прокси-сервер, статические объекты, графические файлы и таблицы стилей запрашиваются с Back-end только при первом обращении к ним. После этого файлы хранятся в кэш Front-end в соответствии с политикой кэширования и отдаются пользователям без обращения к Back-end.

  Цели и задачи

Основные цели, которых мы добиваемся созданием первого Front-end уровня:

• минимизация числа запросов, поступающих к Back-end веб-серверу. Надо добиться ситуации, когда Front-end будет обращаться к Back-end процессам только для получения содержимого PHP-страницы. Все запросы к статическим объектам должны обрабатываться легкими процессами Front-end самостоятельно или при использовании кэширующего прокси-сервера на всех запросах, кроме первого.
  Совет: проверьте лог Back-end веб-сервера, чтобы убедиться, что вы настроили все правильно и действительно исключили лишние запросы. В логе должны быть представлены только страницы PHP, другие запросы не должны проходить к Back-end системе и не будут отражаться в лог файле.

• минимальное потребление оперативной памяти при обработке статических запросов. Число статических запросов существенно превосходит число запросов к PHP-страницам. Процессы Front-end потребляют в среднем 2-5М оперативной памяти и очень незначительно увеличиваются при обработке статических документов. Это позволяет в разы уменьшить потребление оперативной памяти всей системой в целом.
• защита системы от фактора медленных каналов. Как для статических запросов, так и для HTML-страниц, полученных от PHP-процессов Back-end веб-сервера, процессы Front-end могут передавать страницу пользователю достаточно долго, потребляя при этом очень мало оперативной памяти. Таким образом, Front-end, транслируя запрос к Back-end, получает ответ, высвобождает процессы Back-end для обработки других запросов, а сам передает страницу пользователю, снимая фактор медленных каналов. Система приближается к идеальной системе Б в примере, приведенном в уроке Передача данных клиенту.
  Внимание! Убедитесь, что буферы Front-end достаточны, чтобы без ожидания на передаче принять от Back-end всю страницу. То есть фактически буфер в идеале должен быть равен размеру самой большой страницы у вас на сайте.

• механизм защиты Back-end от большого числа запросов за счет ожидания свободных процессов Back-end для продолжения работы. Проверьте и убедитесь, что Front-end будет ожидать 5-10-15 минут, пока не высвободятся процессы Back-end. Наличие такого механизма позволит нам настроить Back-end так, чтобы полностью стабилизировать систему и подготовиться к стрессовым нагрузкам.
  

Как вы видите, появление Front-end позволяет нам снять целую категорию рисков и подготовить систему к дальнейшей работе

ExpiresActive on 
ExpiresByType image/jpeg "access plus 3 day" 
ExpiresByType image/gif "access plus 3 day"

Для работы этого примера необходимо, чтобы веб-сервер позволял переопределение переменных через файл .htaccess и модуль mod_expires был установлен. В некоторых случаях на Front-end политика кеширования настраивается независимо от настроек Back-end.

Таким образом, Front-end будет кешировать все графические изображения. Запросы к контентным страницам не будут кешироваться и будут перенаправляться к Back-end.