Lexa Software: Nginx-ru@sysoev.ru archive

2010/5/6 nickmz <nginx-forum@xxxxxxxx>

Использую связку Nginx + Tomcat/APR - все работает замечательно, спасибо большое за NGINX.

Однако есть следующая забота. При деплое новой версии приложения приходится перезагружать Tomcat, при этом NGINX выдает заранее заготовленную страничку с информацией о том, что на сервисе ведутся технические работы. Сам редеплой достаточно быстрый - не более минуты.

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

Если tomcat входит в качестве веб-сервера / коннектора в какой-то из "полноценных" серверов приложения (JBoss/Geronimo WebSphere / Glassfish...), то вроде правильнее для такой задачи организовать кластер. На выбор: или на уровне нескольких серверов приложений (несколько tomcat /AppServer), или же на уровне самого приложения (когда "кластеризация" выполнена на уровне программной логики - bean / jms / share каких-то состояний, при этом коннектор /веб -сервер общий).

Далее, несколько вариантов
1. [между серверами приложений] шарите данные сессии между экземлярами кластера, и тогда можете относительно спокойно "выключать" обновляемый экземляр, данные текущих сессий будут восстановлены / подхвачены вторым экземляром.
2. [между серверами приложений] отключаете прием новых соединений на обновляемый экземляр, ждете, пока все сессии этого экземляра будут обработаны, после этого спокойно выключаете / обновляете.
3. [приложение] принимающий запросы (load-balancing) код не изменился, и он (внутри приложения) "раздает" (неважно каким образом...) запросы между пулом обрабатывающих запросы bean / компонентами. Здесь аналогично "ждете" (слушая по JMX), когда bean освободится и выгружаете соответствующие ejb/ear... При подгрузке же компонент должен обратно зарегистрировать себя в пуле, и дальше сможет получать новые запросы.

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

2010/5/6 Daniel Podolsky <onokonem@xxxxxxxxx>

другие роботы должны корректно обрабатывать 500 сами.

Для правильных роботов/агентов, вероятно, лучше не 500, а что-то другое...

а человеку лучше
показать "приходите через минуту", чем мариновать его эту минуту.
Представляете, сколько раз он за эту минуту нажмет релоад?

Это зависит от организованной на UI usability...
Вспомните rapidshare. Вы не жмете релоад (пока вам пишут - ждите 10, 9... секунд), потому что это бесполезно....
Если "похожее" сообщение будет у пользователя, он тоже не будет жать Reload. Далее, если клиентское приложение а-ля Rich (Comet / что-то другое), то страница (продложение обработки) может быть возобновлена автоматически - по аналогии как это на gmail ("trying to connect").

Так что не все тут плохо с usability.

Если в текущий момент нагрузка составляет 20 запросов в секунду, то за 60 секунд на пуле Nginx накопится очередь в 1200 запросов - и если подать их все сразу, то 900 запросов будут отклонены, что тоже не очень хорошо. Видимо без реализации выходного пула с ограничение на количество исходящих соединений не обойтись.

да, здесь может понадобиться "какой-то" модуль, но скорее всего он должен "онлайн" "коммуницировать" с самим сервером приложений...

Re: Перегрузка backend - можно л и "попридержать запрос" (N ginx + Tomcat)