Лак Nginx Nginx Django?


13

У мене є програма django, і я хочу встановити Varnish на сервері перед ним. В іншому потоці за замовчуванням хтось запропонував поставити Nginx перед Varnish.

Чи слід ставити Nginx перед Varnish на кешувальному сервері? Якщо так, чи слід використовувати Nginx на сервері додатків?

Відповіді:


10

Ми говоримо про 1 - 3 прифронтових серверах, а не про велику ферму серверів з балансуванням навантаження між ярусами?

Якщо встановити nginx перед Vanish, ви можете робити стиснення HTTP на льоту. Це найкраща практика щодо ефективності, але її можна не обійтися. (Вміст у Varnish часто зберігається нестисненим, так що ESI включає роботу, і тому вам не доведеться мати справу з декількома кешованими версіями одного об’єкта залежно від відповідності заголовка / браузера Vary.)

Що стосується nginx на сервері додатків - чи Apache з mod_wsgi не є рекомендованим та найпоширенішим способом розгортання нових установок Django в даний час? Мені невідомо переконливої ​​причини використання nginx / fastcgi через Apache / mod_wsgi для Django; але вам слід отримати консультацію від експерта Джанго.

Що стосується того, що у Варкі є привабливі функції балансування навантаження, яких немає у nginx, я не бачу, що вони є? Лак має довільне та круглобільне врівноваження. nginx має круглобільний, клієнтський IP та послідовне хешування - я не бачу суттєвої користі для Varnish? Це витончене перезавантаження конфігурації VCL або Varnish чи щось інше?

Я маю на увазі, що для невеликого налаштування сервера 1-3

Лак -> Apache / mod_wsgi / Django

або можливо

Кальмар -> Apache / mod_wsgi / Django

і ігнорувати стиснення HTTP для простоти, якщо тільки пропускна здатність не є дорогою.

Оновлення:

Грем Дамплтон написав цінний коментар нижче. Він згадує дуже поширене налаштування, наприклад, блог на VPS або невелику веб-ферму без кешування:

nginx -> Apache / mod_wsgi / Django

Це дуже хороше рішення з кількох причин:

  1. Просте налаштування
  2. nginx, який має високу швидкість і мінімальні накладні витрати, обробляє статичне обслуговування файлів і з'єднання браузера.
  3. Django працює у відмінній mod_wsgi Graham Dumpleton, рекомендованій платформі для Django.

Причина, про яку я не згадував спочатку, полягає в тому, що ОР, здавалося, вимагає Varnish, дуже високоефективне рішення кешування. Комбінація nginx / Apache / mod_wsgi не може робити кешування із рівнем продуктивності та гнучкості, що відповідає Varnish.


2
Ви навіть можете використовувати 'nginx -> Apache / mod_wsgi / Django', як це роблять багато людей з різних поважних причин.
Грем Дамплтон

4
Інша річ, яку надає nginx у тому випадку використання, який багато хто не усвідомлює, - це те, що nginx ізолює Apache від повільних клієнтів. Це відбувається тому, що вміст запиту до певного розміру не передається за допомогою nginx. Натомість він завантажує заголовки запитів та вміст та лише запит проксі, коли у нього є все. Це означає, що він передає його Apache лише тоді, коли буде доступна вся інформація, необхідна для обробки запиту. Таким чином Apache / mod_wsgi буде зайнятий щонайменше можливим часом, а процеси / потоки не пов'язані повільним клієнтом. Міра буферизації відбувається і в зворотному напрямку, тому Apache також може закінчитися швидше.
Грем Дамплтон

2
@Graham Dumpleton: Дуже приємно тебе тут, сподіваюся, ти залишишся поруч. :-). Що стосується nginx HTTP мультиплексування / розумного керування з'єднаннями, я повністю згоден.
Jesper M

Перш за все, дякую Jesper та Graham, що знайшли час для написання таких вичерпних відповідей. Я планую розмістити сервер балансування навантаження перед двома серверами додатків. Один сервер буде обробляти більшу частину трафіку, другий використовується в основному для відмови та бета-тестування нових функцій.
Енріко

Лак привабливий, тому що дає мені повний контроль над тим, які запити надсилаються до якого бекенда. Лак також перевіряє стан здоров’я задніх серверів, налаштування відмови простий у налаштуванні, і він граціозно обробляє повільні / мертві файли (якщо обидва сервера гинуть).
Енріко

4

Ви можете використовувати nginx без лаку для проксі та кешування вмісту.


2
лак має деякі привабливі можливості збалансування навантаження, які nginx не виходить з коробки
Enrico

4
які особливості, наприклад?
мовчить

4

Я успішно використовую Nginx, Varnish та Apache / mod_wsgi / Django. Я почав із наступної конфігурації:

Nginx -> Apache / mod_wsgi / Django

Як тільки я почав бачити значне навантаження на Apache, я додав лак:

Nginx -> Лак -> Apache / mod_wsgi / Django

Я використовую Nginx як своєрідний "маршрутизатор URL-адрес". Запити адміністратора Django надсилаються безпосередньо з Nginx в Apache. Клієнтські запити надсилаються від Nginx до Varnish, який кешує запити від Apache, а також подає "прикрашені" елементи з кешу, якщо сервери додатків недоступні.

Мій сервер Nginx також безпосередньо подає певний статичний вміст (наприклад, зображення, CSS та файли javascript).

Загалом, продуктивність була відмінна. Я помітив пару застережень, які я повинен зазначити:

  1. На зайнятому сайті перезапуск лаку може спричинити навантаження на сервери додатків, тому краще звести режим перезапуску Varnish до мінімуму. (Здається, у лаку немає "перезавантаження", як Nginx / Apache, де він просто перечитує свої файли VCL). І навпаки, перезавантаження конфігурації Nginx має мінімальний вплив. З цієї причини я більшу частину переписування та "маршрутизації" URL-адрес у Nginx.
  2. Лак легко вводиться між Nginx і Apache. Якщо ви почнете помічати високу завантаженість серверів своїх додатків, додавання лаку навіть з конфігурацією за замовчуванням дійсно може змінити значення.
  3. Якщо ви використовуєте Varnish, вам обов'язково потрібно подумати про те, як ви збираєтеся обробляти помилку кешу.
  4. Мій досвід полягав у тому, що лак обробляє помилкові пакети трохи витонченіше, ніж Nginx (як ви вказували раніше).

Я ніколи не бачив лаку за чимось іншим. Лак - це зазвичай балансир навантаження, який робить маршрутизатор URL. Отже, у вас є 2 веб-сервери та 1 проксі або 2 проксі і 1 веб-сервер? Q
ioanb7

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.