2010/5/6 nickmz <nginx-forum@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@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 ~
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://nginx.org/mailman/listinfo/nginx-ru
