Лак по сравнению с другими обратными прокси
Ну, я выполняю Лак на своих веб-серверах, прежде всего, по причинам производительности, хотя ее функции выравнивания нагрузки удобны также.
Мой вариант использования кэшируется перед находящимися в Django веб-сайтами, и он делает чудеса для выполнения загрузки страницы. Я могу служить большинству страниц непосредственно от кэша и обработать лавинную рассылку посетителей с небольшой проблемой.
Причиной я выбрал Varnish, была главным образом производительность/масштабируемость. Основные моменты:
- Лак позволяет нам, ядро управляет виртуальной памятью, куда Сквид попытки разделить диск и кэши памяти, может привести к ядру и Сквиду, ссорящемуся немного о том, что должно быть разбито на страницы к диску.
- Лак использует VCL, свой собственный зависящий от домена язык конфигурации, который компилирует вниз в машинный код через C. Это - очень реальный выигрыш в производительности, если Вы имеете больше, чем определенная логика в Вашей конфигурации – условный заголовок, разделяющий и т.д.
По моему опыту, Лак работает немного лучше, чем Сквид в большинстве случаев, и намного лучше на транспортных скачках. С другой стороны, конфигурирование Лака правильно собирается взять некоторое траление списка рассылки, так как нет стольких же ready-to-go-for-your-specific-use-case-documentation, текущих по всей сети, сколько существует для Сквида – главным образом должно Лакировать быть довольно молодым проектом в сравнении.
Я провел долгое время, пытаясь получить Лак 1.x стабильный по стандарту трясины Linux/оборудование Dell, он будет всегда зависать некоторым нечетным способом, и его сторожевой таймер перезапустил бы его. Который был прекрасен, за исключением твердого выигранного кэша, который не сохранялся больше нигде...
Однако Вы действительно используете правильный инструмент для задания? Если Вы хотите обратный прокси, который будет кэшировать результаты запроса (предполагающий, что Вы обеспечиваете, заголовки кэша хорошего качества) затем лакируют, хороший вариант. Надо надеяться, это имеет более стабильный в версии 2.0
Однако, если Вы работаете *onRails сайт, и Вы хотите выравнивание нагрузки по нескольким серверам бэкэнда затем, HAProxy или Nginx могут быть способом пойти. Если Вам не будет нужна никакая сложная логика URL (перенаправления, regex соответствия для перезаписи более старых URL, и т.д.) затем, то HAProxy будет отвечать всем требованиям. При необходимости в чем-то более способном то дайте nginx движение.