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 это масштабируемо работать не будет. Нужно
писать преловый скрипт из нескольких обработчиков.
Игорь Сысоев
