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

[Xasima]

2010/5/6 nickmz <nginx-forum at nginx.us>

> Использую связку 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 at gmail.com>

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


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

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

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

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



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











-- 
Best regards,
    ~ Xasima ~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20100506/58f69902/attachment.html>