ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ngx_http_perl_module - исследова ние



On Wed, 18 Jan 2006, Andrew Velikoredchanin wrote:

Igor Sysoev пишет:
On Wed, 18 Jan 2006, Andrew Velikoredchanin wrote:

16 воркеров (и выше):

Time per request:       2077.931 [ms] (mean)
Time per request: 207.793 [ms] (mean, across all concurrent requests)

Вот тут не совсем понятно. По идее, если-бы параллельные запросы раздавались сразу на все воркеры, то значения должны были-бы быть в районе 1 секунды и 100 мс. В данном случае не совсем понятна логика распределения запросов.


Игорь, можете прокомментировать эти данные?

Если не стоит "events { multi_accept on }" и используется epoll, то это
объясняется так: nginx принял одно соединение и добавил его в epoll, затем
опять вызвал epoll_wait(), он может вернуть два события: первое - новое
соединение и второе - готовность данных для первого соединения. Таким образом,
nginx получил два соединения перед sleep().

Т.е. получается, что есть ограничение которое не позволит добиться более гладкой работы скрипта в нескольких параллельных запросах за счет увеличения количества воркеров? Или я что-то не так понял?

В принципе, можно сделать так, чтобы nginx принимал бы ровно одно соединение,
и не вызывал бы accept() до тех, пор не облсужит это соединение до той
стадии, когда перл отработает, но это получится Apache :)

Если перл работает, съедая процессор, то толку от параллельности мало,
процессор-то делится между всеми воркеарми. А вот если перл просто
чего-то ждёт, то в nginx это масштабируемо работать не будет. Нужно
писать преловый скрипт из нескольких обработчиков.


Игорь Сысоев
http://sysoev.ru



 




Copyright © Lexa Software, 1996-2009.