Лак проти інших зворотних проксі

Я працюю з організацією, яка розгорнула Varnish як зворотний проксі-сервер кешування для всього їх веб-трафіку. Їхній трафік складає багато динамічних веб-сайтів, що створюються клієнтами, а звичайна колекція статичних активів висить збоку.

Хоча я намагаюся любити лак (я думаю, що він має досить гарну архітектуру, в принципі), у мене виникають деякі проблеми з управлінням та усунення неполадок у міру їх виникнення, тому мені цікаво, чи це дійсно правильний вибір. Раніше я використовував кальмари як зворотний проксі, але не в таких же ролях, тому я не маю чіткої основи для порівняння.

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

Добре, що я запускаю Varnish на своїх веб-серверах, в першу чергу з міркувань продуктивності, хоча зручні також функції його балансування навантаження.

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

Причиною, що я обрав лак, була головним чином продуктивність / масштабованість. Основні моменти:

• Лаком давайте ядро ​​керувати віртуальною пам’яттю, де Squid намагається зберігати окремі кеші диска та пам'яті, може призвести до того, що ядро ​​та Squid трохи посперечаються з приводу того, що потрібно підписати на диск.
• Лак використовує VCL, це власна мова конфігурації домену, яка збирається до машинного коду за допомогою C. Це дуже реальна користь від продуктивності, якщо у вашій конфігурації є трохи більше логіки - умовна зачистка заголовка тощо.

На моєму досвіді, лак у більшості випадків трохи краще, ніж кальмари, і набагато краще на шинах руху. З іншого боку, якщо правильно налаштувати Varnish, буде проведено деяке трасування списків розсилки, оскільки не так багато документації, готової до переходу на ваш конкретний для використання випадок, що протікає по мережі, скільки є для кальмарів - головним чином завдяки тому, що Varnish є досить молодим проектом порівняно.

Я витратив тривалий час, намагаючись отримати Varnish 1.x стабільний на стандартному обладнання для Linux / Dell, він завжди зависав би якось дивно, і його сторожовий собака перезапустив би його. Що було добре, за винятком важко виграного кешу, який не зберігався ніде ...

Сказавши це, чи справді ви використовуєте правильний інструмент для роботи? Якщо ви хочете зворотний проксі-сервер, який буде кешувати результати запиту (якщо ви надаєте заголовки кешу хорошої якості), то лак - хороший варіант. Сподіваємось, він стає більш стабільним у версії 2.0

Однак якщо ви працюєте на сайті * onRails і хочете завантажувати балансування на декількох серверах задніх серверів, то HAProxy або Nginx може стати дорогою. Якщо вам не потрібна якась складна логіка URL-адреси (переспрямовування, збіги з регулярними виразами для перезапису старих URL-адрес тощо), HAProxy підходить до рахунку. Якщо вам потрібно щось більш здатне, то дайте nginx піти.