Масштабируя node.js приложение, nginx как основной сервер, но лак или советы для кэширования?

Для чисто статического контента вы обычно получаете очень мало преимуществ, если запускаете Varnish перед любым зрелым веб-сервером, таким как nginx или Apache. (Я не могу говорить о node.js, потому что я еще не использовал его.) Причина этого в том, что ядро ​​поддерживает кеш файловой системы, который хранит файлы, к которым недавно осуществлялся доступ, в ОЗУ. Возможно, что Varnish немного лучше, чем ядро, выбирает именно , какие файлы хранить в кэше, а какие извлекать, но также возможно, что он работает хуже. Это будет зависеть от того, что еще делает ваша система, а также от различий в политиках хранения кеша. Дополнительная задержка, вызванная наличием прокси перед вашим веб-сервером, намного превзойдет любые различия между кешированием файловой системы Varnish и ядра.

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

Varnish может кэшировать динамический контент, и в этом его преимущество. Допустим, для первой страницы вашего веб-сайта требуется компиляция кода PHP и 20 запросов к базе данных в холодных кэшах. В теплых кэшах (APC, memcached, Redis, MySQL query cache и т. Д.) Он по-прежнему требует поиска в memcached / Redis и выполнения stat () для каждого файла PHP, включенного в запрос. Предполагая, что у вас есть достаточно хорошо оптимизированный сайт, это, вероятно, будет составлять не менее 1/10 секунды (и это довольно хорошо оптимизировано; по моему опыту, 1–3 целых секунды гораздо более распространены). Varnish с радостью отобразит ту же страницу менее чем за 1/1000 секунды. Но это означает, что ваши пользователи не могут войти в систему на главной странице вашего веб-сайта, потому что они не могут получить свои заголовки Cookie: , но если это приемлемо для вас, Varnish - легкая победа.

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

Если вам не хватает опыта для самостоятельного тестирования ваших настроек, сейчас самое время получить этот опыт. Вы проводите сравнительный анализ, чтобы оценить соответствие ваших конфигураций. Попробуйте что-нибудь и запустите ab поверх него, затем измените один и запустите ab точно таким же образом для этой конфигурации. Теперь вы знаете, какой из них «лучше». Промыть, повторить. (Кроме того, всегда запускайте ab дважды и игнорируйте первый результат. Это гарантирует, что вы проверяете только теплые кеши и не ошибочно думаете, что одна конфигурация хуже, потому что она тестировалась на холодных кэшах. )

Создание масштабируемого решения для вашего веб-сайта - достаточно сложная тема, и она не вписывается в ответ ServerFault. Мы определенно можем помочь с отдельными частями этого (например, «Как мне масштабировать мой сервер memcached до кластера memcached?»), Когда вы столкнетесь с этими проблемами.

Дальнейшее чтение:

Я написал ответ некоторое время назад, в котором был раздел о поиске узкого места при тестировании .
Уомбл недавно указал мне на отличный пост о поиске узких мест .