Роль Varnish cache

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

По сравнению с nginx вы не заметите значительной разницы в производительности для обслуживания небольших, часто используемых, статических файлов, если вы используете Varnish. Причина в том, что хорошо настроенный nginx будет обслуживать статические файлы напрямую (то есть не будет передавать запрос в PHP), а ваша операционная система кэширует запросы к диску (что означает, что они, по сути, все равно обслуживаются из памяти).

Вы можете получить значительную выгоду от Varnish, если сможете кэшировать динамический контент. Рассмотрим статью или домашнюю страницу, которые не так часто меняются относительно количества просмотров (даже если они меняются каждые 5 минут, но получают за это время 100 просмотров, изменение минимально). Преимущество здесь в том, что Varnish может кэшировать копию вашей динамической страницы и обслуживать ее непосредственно для ваших пользователей. Это значительно снижает необходимость в повторном создании динамических страниц, что обычно требует больших вычислительных ресурсов. (Это не только приводит к меньшей нагрузке на PHP, но также снижает нагрузку на MySQL - в результате запросы, которые действительно должны обрабатываться серверной частью, могут быть возвращены быстрее).

При правильной настройке Varnish позволит вам удалять отдельные файлы из кеша по мере появления обновлений для них, что не позволяет вам обслуживать устаревшие копии. Более того, Varnish позволяет довольно точно контролировать то, как хранятся кеши, что позволяет не кэшировать определенные страницы (например, те, которые относятся к зарегистрированным пользователям и т. Д.), Кешировать страницы на основе IP-адресов запрашивающей стороны, изменять заголовки и т. Д. .

Напомним: в вашей среде (nginx + php-fpm + APC) преимущество Varnish может заключаться в уменьшении количества запросов на динамические страницы, которые достигают серверной части. Если вы собираетесь использовать его только для статических ресурсов, я бы посоветовал вам просто придерживаться nginx.

В другой настройке (например, Apache) обслуживание статических ресурсов из Varnish имело бы большой смысл.

Даже если у вас есть свободная память, улучшение производительности, предлагаемое Varnish для статических ресурсов по сравнению с nginx, не так заметно, как для динамических страниц.

(Следует отметить, что nginx действительно предлагает fastcgi_cache, но он не предоставляет столько возможностей, сколько Varnish, что, как мне кажется, делает Varnish более подходящим для кеширования динамических страниц).

Изменить: APC

PHP - это интерпретируемый язык: вы пишете сценарии, которые затем запускаются через интерпретатор и преобразуются в форму, понятную для базовой операционной системы. APC - это кеш кода операции - он специфичен для PHP (хотя аналогичные продукты могут существовать для других языков).

По сути, APC хранит промежуточные продукты процесса «компиляции», чтобы последующие вызовы того же кода могли обрабатываться быстрее. Это означает, что если вы запускаете один и тот же код несколько раз, первый вызов пройдет полный процесс интерпретации, а следующие запросы смогут использовать предварительно обработанный код - что и приводит к ускорению, которое дает APC.

Более того, APC работает не с полными файлами PHP, а с частями файла, поэтому, если вы используете (например, через включение) одну и ту же функцию в двух отдельных сценариях PHP, кешированная копия функции будет полезна для обоих сценариев.

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

В отличие от Varnish, который хранит окончательный, «статический» вывод, сгенерированный сценарием (то есть тот, который отправляется пользователю), APC хранит гораздо более динамическую версию - функция, которая дает разные результаты для каждого ввода, получит пользу от APC. , но не от Varnish.

По сути:

• Varnish сохраняет копию того, что ваш PHP-скрипт будет отправлять пользователю - попадания в кеш Varnish полностью обходят серверную часть (попадание будет означать, что ни nginx, ни php / mysql в любом случае не задействованы, контент обслуживается прямо из кеша)
• APC ускоряет PHP, поэтому, когда запрос все-таки попадает в PHP, он может быть обработан быстрее.

APC и Varnish выполняют разные функции, и вы, безусловно, можете использовать их вместе, что принесет максимальную пользу.

Считается с другой стороны - всегда будет быстрее не использовать PHP / MySQL - статические страницы (по сути, то, что составляет кэшированная копия) быстрее, чем динамические страницы, но когда вам действительно нужно обслуживать динамическую страницу, вы хотите сделать ее как как можно быстрее.

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

Varnish cache - это ускоритель веб-приложений, также известный как кэширующий обратный HTTP-прокси. Он действует больше как посредник между вашим клиентом (то есть пользователем) и вашим веб-сервером. Это означает, что вместо того, чтобы ваш веб-сервер постоянно постоянно прослушивал запросы с определенным содержанием, Varnish берет на себя ответственность.

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

PHP Varnish использует язык конфигурации Varnish (VCL), чтобы вы могли изменять его поведение, добавляя логику для управления запросами. Вы можете управлять ответом, возвращаемым с веб-сервера, удалять файлы cookie или добавлять заголовки в ответ.

Лак рабочий процесс

Get / some-web-page (клиент) - → Cache - → Get / some-web-page (Server) —- → Cache - → Back to client.

Предположим, что первый запрос страницы занимает около 200 мс.

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

GET / some-web-page (клиент) - → Cache (HIT). —–> И обратно к клиенту

Последующий запрос на страницу 10мс… ..

Круто, правда?

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

Вы можете прочитать всю статью Вот.

Лак особенно хорош для обслуживания «статического» контента.

например. изображения, js, css

Так что, если на вашем сайте много статического контента, который редко меняется, вы можете пропустить необходимость просматривать весь стек сервера и просто перейти к Varnish.