У Varnish есть несколько преимуществ. Первое, что вы заметите, - это снижение нагрузки на внутренний сервер. Обычно путем кеширования содержимого, которое создается динамически, но редко изменяется (по сравнению с тем, как часто к нему обращаются). Если взять ваш пример Wordpress, большинство страниц, по-видимому, меняются не очень часто, и существуют некоторые плагины, которые делают недействительными кеш-лак при изменении страницы (например, новая запись, редактирование, комментарий и т. Д.). Следовательно, вы кешируете на неопределенный срок и аннулируете при изменении, что приводит к минимальной нагрузке на ваш внутренний сервер.

Несмотря на связанную со ссылкой статью, большинство людей считают, что Varnish работает лучше, чем Nginx при правильной настройке - хотя (и я действительно не хочу это признавать), мои собственные тесты, похоже, подтверждают, что nginx может обрабатывать статический файл быстрее, чем varnish ( к счастью, я для этого не использую лак). Я думаю, что проблема в том, что если вы в конечном итоге используете Varnish, вы добавили дополнительный слой в свою настройку. Прохождение этого дополнительного уровня на внутренний сервер всегда будет медленнее, чем простое обслуживание непосредственно с внутреннего сервера - и именно поэтому разрешение Varnish кэшировать может быть быстрее - вы экономите шаг. Другое преимущество - наличие disk-io. Если вы настроили varnish для использования malloc, вы вообще не попали на диск, что оставляет его доступным для других процессов (и обычно ускоряет работу).

Я думаю, что нужен лучший тест, чтобы действительно оценить производительность. При неоднократном запросе одного и того же файла запускаются кеши файловой системы, которые начинают смещать фокус с самих веб-серверов. Лучшим тестом было бы использовать осаду с несколькими тысячами случайных статических файлов (возможно, даже из журналов вашего сервера) для имитации реалистичного трафика. Возможно, однако, как вы упомянули, становится все более распространенным выгрузка статического контента в CDN, что означает, что Varnish, вероятно, не будет обслуживать его с самого начала (вы упомянули S3).

В реальном сценарии вы, скорее всего, расставите приоритеты в использовании памяти - в первую очередь, динамический контент, поскольку его создание является наиболее дорогостоящим; затем небольшой статический контент (например, js / css) и, наконец, изображения - вы, вероятно, не будете кэшировать другие носители в памяти, если у вас нет действительно веских причин для этого. В этом случае, когда Varnish загружает файлы из памяти, а nginx загружает их с диска, Varnish, скорее всего, превзойдет nginx (обратите внимание, что кеши nginx предназначены только для проксирования и fastCGI, и они по умолчанию основаны на диске, хотя это можно использовать nginx с memcached).

(Мой быстрый - очень грубый, не заслуживающий доверия - тест показал, что nginx (direct) был самым быстрым - назовем его 100%, varnish (с malloc) был немного медленнее (около 150%), а nginx позади varnish ( с проходом) был самым медленным (около 250%). Это говорит само за себя - все или ничего - добавление дополнительного времени (и обработки) для связи с серверной частью просто означает, что если вы используете Varnish и у вас есть ОЗУ в запасе , вы можете просто кэшировать все, что можете, и передавать его из Varnish вместо того, чтобы передавать обратно в nginx.)

Для динамическое содержимое, что-то вроде котировок акций на самом деле часто меняется (обновляется каждую секунду SaaS server из backend server), но может запрашиваться еще чаще (десятками тысяч subscription clients):

[stock calculation / backend server] ----- [SaaS server] ------ [subscription clients]

В таком случае, кеширование на SaaS server посекундное обновление от backend servers позволяет удовлетворить запросы десятков тысяч subscription users.

Без кеша на сервере SaaS эта модель просто не работала бы.

Я думаю, тебе что-то не хватает.

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

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

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

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

В приведенном выше фрагменте кода вы видите очень типичный фрагмент VCL Varnish, который заставляет кэшировать изображения, CSS и javascript. По умолчанию Varnish не кэширует запросы, содержащие cookie. Логика заключается в том, что если в запросе есть файл cookie, то должна быть какая-то причина, по которой серверу нужен этот файл cookie, поэтому он требуется на внутренней стороне и должен быть передан через кеш. На самом деле, многие CMS (Drupal, Wordpress и т. Д.) Прикрепляют файлы cookie почти ко всему, независимо от того, требуется это или нет, поэтому обычно пишут VCL для удаления файлов cookie из содержимого, которое, как известно, является статическим, что, в свою очередь, приводит к кешированию Varnish Это.

Есть смысл?

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

Для статических файлов: кэшировать на HDD. Для всего остального: кешировать в RAM.

Это должно дать вам больше информации о том, как реализовать этот сценарий: http://www.getpagespeed.com/server-setup/varnish-static-files-cache