Я не очень хорошо разбираюсь в nginx или varnish, но на данный момент это моя установка.
У меня работает сервер node.js, который обслуживает либо json, html шаблоны, либо события socket.io. Затем у меня есть nginx, работающий перед узлом, который обслуживает весь статический контент (css, js и т. Д.).
На этом этапе я хотел бы кэшировать как статический, так и динамический контент в памяти.
Насколько я понимаю, лак может достаточно хорошо кэшировать статический контент, и для этого не потребуется трогать код моего приложения. Я также думаю, что он также может кэшировать динамический контент, но не может быть заголовков файлов cookie?
В настоящее время я использую redis для хранения данных сеанса и планировал использовать его для других целей в будущем, например, для отслеживания не важной, но интересной статистики.
Я просто не знаю, как мне обращаться с кешированием всего на сайте. Я думаю, что все сводится к этим вариантам, но их может быть больше:
Добавьте varnish перед nginx и позвольте varnish кешировать статические страницы без изменений кода приложения. Redis будет кэшировать динамические вызовы db, что потребует изменения кода моего приложения.
Полностью игнорируйте использование varnish и позвольте redis обрабатывать кеширование всего, а затем используйте один из модулей nginx-redis. Я не уверен, что для этого потребуется много изменений кода приложения (для статических файлов).
Мне не удалось найти тесты, которые сравнивают nginx + varnish против nginx + redis, и я слишком неопытен, чтобы тестировать его сам (высокие шансы, что мои конфигурации будут ужасными).
Я в основном ищу решение, которое было бы наиболее эффективным с точки зрения запросов в секунду и масштабируемым в будущем (добавьте новое оборудование в проблему + возможно, скорректируйте некоторые значения в конфигурации = новые серверы будут запущены и работают безболезненно) .
Для чисто статического контента вы обычно получаете очень мало преимуществ, если запускаете Varnish перед любым зрелым веб-сервером, таким как nginx или Apache. (Я не могу говорить о node.js, потому что я еще не использовал его.) Причина этого в том, что ядро поддерживает кеш файловой системы, который хранит файлы, к которым недавно осуществлялся доступ, в ОЗУ. Возможно, Varnish справляется с выбором чуть лучше, чем ядро. который файлы, которые нужно хранить в кеше и которые нужно извлечь, но также возможно, что он работает хуже. Это будет зависеть от того, что еще делает ваша система, а также от различий в политиках хранения кеша. Дополнительная задержка, вызванная наличием прокси перед вашим веб-сервером, намного превзойдет любые различия между кешированием файловой системы Varnish и ядра.
Вы правы насчет Varnish не кэширует ответы, отправленные с Set-Cookie: заголовок. Он также пропускает просмотр кеша, если запрос содержит Cookie: заголовок. Причина этого в том, что будет один такой уникальный ответ для каждого пользователя, который посещает любую данную страницу, и каждый пользователь вряд ли повторно посетит одну и ту же страницу, что означает, что ваш кеш будет заполнен объектами, которые никогда не будут использоваться.
Лак жестяная банка кешировать динамический контент, и именно здесь он сияет. Допустим, для первой страницы вашего веб-сайта требуется компиляция кода PHP и 20 запросов к базе данных в холодных кэшах. В теплых кэшах (APC, memcached, Redis, MySQL query cache и т. Д.) Он по-прежнему требует поиска в memcached / Redis и выполнения stat() для каждого файла PHP, включенного в запрос. Предполагая, что у вас достаточно хорошо оптимизированный сайт, это, вероятно, будет составлять не менее 1/10 секунды (и это довольно хорошо оптимизировано; по моему опыту, 1–3 полных секунды гораздо чаще). Varnish с радостью отобразит ту же страницу менее чем за 1/1000 секунды. Но это означает, что ваши пользователи не могут войти в систему на главной странице вашего сайта, потому что они не могут получить свои Cookie: заголовки, но если это приемлемо для вас, Varnish - легкая победа.
Лак также требует правильных заголовков кеширования. Если он не уверен, что кэшировать объект безопасно, он не будет. Если вы соответствуете всем этим требованиям, Varnish может стать для вас инструментом. Тем не менее, простая установка правильных заголовков приведет к тому, что клиенты сами будут кэшировать контент, что может иметь гораздо большее значение, чем Varnish.
Если вам не хватает опыта, чтобы самостоятельно протестировать свою настройку, сейчас самое время получить этот опыт. Вы проводите сравнительный анализ, чтобы оценить соответствие ваших конфигураций. Попробуйте что-нибудь и бегите ab над ним, затем измените один вещь и беги ab точно так же с этой конфигурацией. Теперь вы знаете, какой из них «лучше». Промыть, повторить. (Кроме того, всегда запускайте ab дважды и игнорируйте первый результат. Это гарантирует, что вы тестируете только теплые кеши и не будете ошибочно думать, что одна конфигурация хуже, потому что она была протестирована против холодных кешей.)
Создание масштабируемого решения для вашего веб-сайта - достаточно сложная тема, поэтому она не вписывается в ответ ServerFault. Мы, безусловно, можем помочь с отдельными частями этого (например, «Как мне масштабировать мой сервер memcached до кластера memcached?»), Когда вы столкнетесь с этими проблемами.
Дальнейшее чтение:
Некоторое время назад я написал ответ, в котором был раздел о поиск узких мест при сравнительном анализе.
Уомбл недавно указал мне на отличный пост о поиске узких мест.