On Wed, 23 Jul 2003, Konstantin Morshnev wrote:
> А на самом деле получается что MW это (если опять ничего не путаю :) число
> процессов, тоже ждущих ответы на те же запросы, которые сейчас обрабатывает
> backend...
Да, именно так. Эта фича появилась после того, как я столкнулся с
ситуацией, когда все Апачи соединялись с тормозным бэкендом и обрабатывать
непроксированные запросы было некому.
> То есть в приведенной ситуации если пустить запросы:
>
> 00:00 (1) page1.html - пошел запрос к backend на page1.html, connected=1
> 00:01 (2) page2.html - 503
> 00:02 (3) page3.html - 503
> 00:03 (4) page1.html - waiting=1
> 00:04 (5) page4.html - 503
> ...
> 00:10 (1) page1.html отдается из backend и кладется в cache
> 00:10 (4) page1.html отдается из cache.
>
> Положение понятно, но мне кажется более логичным (и удобным) такое поведение:
Да, именно так.
> 00:00 (1) page1.html - пошел запрос к backend на page1.html, connected=1
> 00:01 (2) page2.html - waiting=1
> 00:02 (3) page3.html - waiting=2
> 00:03 (4) page1.html - waiting=3
> 00:04 (5) page4.html - waiting=4
> ...
> 00:10 (1) page1.html отдается из backend и кладется в cache
> 00:10 (4) page1.html отдается из cache.
> 00:10 (2) на backend отдается запрос к backend на page2.html
> ...
В mod_accel я этого делать точно не буду. Возможно, подобная фича появиться
в скором light-weight http и реверз-прокси сервере.
> Хотя этого действительно можно добиться через очередь на accept, но ее размер
>в
> любом случае существенно ограничен, и да и перекомпилировать ради этого ядро
> кажется странным. Опять же если backend не apache, у него может не
>настраиваться
> аналог MaxClients. Ну да ладно... :)
Во FreeBSD 3.4+ (а может и раньше) это меняется на лету через sysctl
kern.ipc.somaxconn. В некоторых местах у меня стоит backlog 5000.
Я не думаю, что это существенно ограничен.
Хотя, конечно, данный способ не везде возможен.
Игорь Сысоев
