Век живи и век учись... или про httpqueuemethod

[rinsk]

Решил разместить тут - ибо имхо полезно.
Жило-было некое довольно крупное веб классик приложение и у него было кой-какие проблемы с производительностью, которые я взялся решить. Дабы зафиксировать прогресс коллеги решили протестить это приложение средствами автоматического тестирования... ну и сказали свое фи... ибо 10 процессов логина разными пользаками проходили ну оч уж медленно (с одного ип). Долго разбирался и поставил оставил HTTPQueueMethod=2 (стоял=1) и результат оказался оч. хорошим. Все шустро летало. Прошло время, кол-во пользаков выросло раза в 3 и тут сервер стал просто загибаться от кол-ва запросов. Долго мучился с оптимизацией - а потом вспомнил про это параметр. Выставил HTTPQueueMethod=1 и сразу нагрузка на сервер упала.
Описание параметра: link removed

 

[ToxaRat]

поподробнее с цифрами и статистикой
ничего не понял

 

[rinsk]

Что конкретно интересует?
Вот текущая загрузка сервера - 250 пользователей одновременно сидит. всего около 1500 юзверей. раньше загрузка была под 90% всех процессоров.
Скажу сразу - приклада старая - куча вызовов ?OpenAgent и тп. Переделывать на икпейджи и т.п. - дорого и не стоит вообще то)

 

[rinsk]

@ToxaRat, каменты будут? или мож у коллег есть опыт настройки http домино. речь не идет об inotes - там зализано все что можно. Интересны самодельные приклады под http - xpages в том числе на большом кол-ве пользователей..

 

[lmike]

ну... когда все 12 ядер исчерпываются... тупка и наступает

 

[rinsk]

ну... когда все 12 ядер исчерпываются... тупка и наступает

вооо! А нафига им всем сразу 12 ядер? Вот при HTTPQueueMethod=2 оно в кол-ве Number active threads: сразу налетают на ядра и блокируют друг друга... эта настройка имхо подходит для статичных сайтов - где только виды и статик доки. При HTTPQueueMethod=1 - запрос от клиента "вытягивается в трубочку " и обрабатывается последовательно - что более подходит для динамических сайтов с большим объемом вычислений на агентах например. Медленно - но верно

 

[ToxaRat]

вооо! А нафига им всем сразу 12 ядер? Вот при HTTPQueueMethod=2 оно в кол-ве Number active threads: сразу налетают на ядра и блокируют друг друга... эта настройка имхо подходит для статичных сайтов - где только виды и статик доки. При HTTPQueueMethod=1 - запрос от клиента "вытягивается в трубочку " и обрабатывается последовательно - что более подходит для динамических сайтов с большим объемом вычислений на агентах например. Медленно - но верно

всё равно я не могу понять а зачем менять то?
перед домино ставим любой кешер и всё разве нет?
и как получилось что HTTPQueueMethod пришлось менять дважды? сначала в одно сторону, потом в другую, что изменилось?

 

[rinsk]

не - кешер не пойдет - сильно динамичный контент. А менял - по тому что не соображал четко - как надо и каков реально эффект от этого параметра))
Теперь сообразил... надеюсь.

 

[ToxaRat]

не - кешер не пойдет - сильно динамичный контент

не верю, в динамике может быть текст, но никак не картинки и прочие ресурсы

 

[rinsk]

не верю, в динамике может быть текст, но никак не картинки и прочие ресурсы

Я картинки вообще не рассматриваю - они на nginx живут и не тужат. - ресурсы базы в виде css\js норм отрабатывают по Etag.Там все построено на аяксах + WQO\WQS агентах - это и считаю дин . контентом.
Дело в распределении потоков http таска в зависимости от настроек HTTPQueueMethod.

 

[ToxaRat]

всё равно не понимаю, какая разница конечному пользователю от количество потоков?
ему главное чтобы всё отзывалось в течении секунды, правильно?

 

[rinsk]

@ToxaRat, ок. опустимся на уровень пользователя...
короч - щас все довольны