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

[Igor Sysoev]

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