Лак против других обратных прокси

Я работаю с организацией, которая развернула Varnish в качестве обратного прокси-сервера для всего своего веб-трафика. Их трафик состоит из множества динамических веб-сайтов, генерируемых клиентами, с обычным набором статических ресурсов, свисающих со стороны.

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

Мой вопрос нацелен на людей, которые развернули лак в производстве или серьезно оценили его по сравнению с альтернативами: вы придерживались лака, или вы в конечном итоге использовали другой обратный прокси-сервер? Каковы были ваши ключевые моменты для того, чтобы остаться с ним или переключиться, и если вы использовали что-то еще, что вы в конечном итоге использовали?

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

Мой пример использования - кэширование перед сайтами, основанными на Django , и это удивительно для производительности загрузки страниц. Я могу обслуживать большинство страниц непосредственно из кэша и справляться с потоком посетителей без особых проблем.

Причиной, по которой я выбрал Varnish, была производительность / масштабируемость. Основные моменты:

• Лакирование позволяет ядру управлять виртуальной памятью, где Squid пытается хранить отдельные кэши диска и памяти, может привести к тому, что ядро ​​и Squid немного поспорят о том, что нужно перенести на диск.
• Varnish использует VCL, свой собственный язык конфигурации, специфичный для домена, который компилируется в машинный код через C. Это очень реальный выигрыш в производительности, если у вас есть более чем немного логики в вашей конфигурации - условное удаление заголовка и т. Д.

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

Я потратил много времени, пытаясь добиться стабильной работы Varnish 1.x на стандартном оборудовании linux / dell, оно всегда зависало каким-то странным образом, и его сторожевой таймер перезапускал его. Что было хорошо, за исключением жесткого кеша, который больше нигде не сохранялся ...

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

Однако, если вы работаете с сайтом * onRails и хотите, чтобы балансировка нагрузки выполнялась на нескольких внутренних серверах, тогда HAProxy или Nginx могут быть подходящим вариантом. Если вам не нужна какая-либо сложная логика URL (перенаправления, совпадения с регулярными выражениями для перезаписи более старых URL и т. Д.), Тогда HAProxy будет соответствовать всем требованиям. Если вам нужно что-то более способное, попробуйте nginx.