Наскільки добре nginx та memcached працюють разом?

У нас є веб-додаток на базі Java EE, що працює на сервері кластерних програм Glassfish . Вхідний трафік в основному буде RESTful запитами для представлень ресурсів нашого додатка на основі XML, але, можливо, 5% трафіку може бути для представлень на основі JSON або XHTML / CSS.

Зараз ми досліджуємо рішення щодо балансування навантаження для розподілу вхідного трафіку по всіх екземплярах Glassfish у кластері. Ми також розглядаємо, як вивантажити кластер за допомогою простроченої хеш-карти, розподіленої в пам'яті, чиїми ключами будуть імена ресурсів REST (наприклад, "/ користувач / bob", "/ group / jazzlovers") та значення яких: відповідні представлення XML

Один із підходів, який звучить багатообіцяюче, - це вбити обох птахів одним каменем і використовувати легкий, швидкий nginx сервер HTTP / зворотний проксі. Nginx буде обробляти кожен вхідний запит, спершу переглянувши його URI в запам’ятовуваному вигляді, щоб побачити, чи немає в ньому ще не закінченого представлення XML. Якщо ні, nginx надсилає запит до одного з екземплярів Glassfish. Модуль, що запам'ятовується nginx, описаний у цьому короткому описі .

Яке ваше загальне враження від nginx та memcached, використовуваних таким чином, наскільки ви щасливі з ними? Які ресурси вам виявилися найбільш корисними для того, щоб дізнатися про них? Якщо ви спробували їх, і вони не відповідали вашим цілям, чому б ні, і що ви використовували натомість?

Примітка. Ось відповідне питання . Перш ніж я дізнався про ServerFault, я запитав це в StackOverflow .

Редагувати: Усі відповіді тут поки що були дуже корисними, хоча прямого досвіду не було. Ця відповідь в кінцевому підсумку з’явилася на StackOverflow, і вона була досить бичачою в налаштуваннях nginx / memcached.

Ви дійсно повинні використовувати кеш-сервер перед веб-серверами. Я рекомендую Varnish-кеш. Ми використовуємо його в роботі з найбільшим і найнавантаженим веб-сайтом у Скандинавії. Ми замінили 13 сильно завантажених ящиків кальмарів на 1 ящик для лаку та 1 на запасний.

Я націлив простий додаток на своєму приватному веб-сайті, і він перейшов від 9 запитів в секунду до понад 2000.

Ви вирішите, як довго він зберігає речі в пам'яті, ви можете зробити до кінця часу, а потім просто надіслати запит на очищення http на сервер кешу, коли дані змінюються.

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

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

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

Крім того, врахуйте таку ситуацію: коли користувач перебуває в аут-сторінці, сторінка виглядає інакше, з додатковими функціями, доступними та індивідуалізованими для кожного користувача. URL-адреси однакові для зручності посилань і т.д. У таких випадках nginx буде непридатним, тому що ви не можете відрізнити зареєстрованого користувача від несанкціонованого.

Якщо вам не потрібен SSL, я б запропонував вам запустити Varnish. Він був розроблений як прискорювач HTTP, а не як веб-сервер чи проксі. Якщо вам потрібен SSL, запустіть nginx зверху як прискорювач SSL і лакуйте як звичайний прискорювач HTTP, оскільки лак не може мати справу з SSL.

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

мій вибір - хапрокси. Дуже маленький і дуже швидкий зворотний проксі, але це не проксі-кеш! Я використовую для своєї кеш-системи "Squid Web Proxy"

CACHE /squid/ -> Load-balancing /Haproxy/ -> WEB I /lighttpd/
                                          -> WEB II /lighttpd/
                                          -> WEB III /lighttpd/

Ця робота ідеально підходить для моєї веб-системи