Застрял на 100 запросах uWSGI

httperf ... --rate=20 --send-buffer=4096 --recv-buffer=16384 --num-conns=100 --num-calls=10

Дает 1000 запросов, как ожидалось, на nginx.Застрял на 100 запросах uWSGI

Total: connections 100 requests 1000 replies 1000 test-duration 5.719 s 

Connection rate: 17.5 conn/s (57.2 ms/conn, <=24 concurrent connections) 
Connection time [ms]: min 699.0 avg 861.3 max 1157.5 median 840.5 stddev 119.5 
Connection time [ms]: connect 56.9 
Connection length [replies/conn]: 10.000 

Request rate: 174.8 req/s (5.7 ms/req) 
Request size [B]: 67.0 

Reply rate [replies/s]: min 182.0 avg 182.0 max 182.0 stddev 0.0 (1 samples) 
Reply time [ms]: response 80.4 transfer 0.0 
Reply size [B]: header 284.0 content 177.0 footer 0.0 (total 461.0) 
Reply status: 1xx=0 2xx=1000 3xx=0 4xx=0 5xx=0 

CPU time [s]: user 1.42 system 4.30 (user 24.9% system 75.1% total 100.0%) 
Net I/O: 90.2 KB/s (0.7*10^6 bps) 

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0 
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

На том же аппаратном запросе uWSGI на порт 8000 выводится 200 запросов и 100 ответов, а также 100 сбросных соединений. Что не так? Сервер чрезвычайно мощный.

Total: connections 100 requests 200 replies 100 test-duration 5.111 s 

Connection rate: 19.6 conn/s (51.1 ms/conn, <=5 concurrent connections) 
Connection time [ms]: min 69.5 avg 128.4 max 226.8 median 126.5 stddev 27.9 
Connection time [ms]: connect 51.4 
Connection length [replies/conn]: 1.000 

Request rate: 39.1 req/s (25.6 ms/req) 
Request size [B]: 67.0 

Reply rate [replies/s]: min 19.8 avg 19.8 max 19.8 stddev 0.0 (1 samples) 
Reply time [ms]: response 68.8 transfer 8.2 
Reply size [B]: header 44.0 content 2053.0 footer 0.0 (total 2097.0) 
Reply status: 1xx=0 2xx=100 3xx=0 4xx=0 5xx=0 

CPU time [s]: user 1.87 system 3.24 (user 36.6% system 63.4% total 100.0%) 
Net I/O: 42.6 KB/s (0.3*10^6 bps) 

Errors: total 100 client-timo 0 socket-timo 0 connrefused 0 connreset 100 
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

источник

2011-12-15 Dmitry

tcp_max_syn_backlog is 1024 somaxconn is 2048 – Dmitry

Это больше логики ответ:

http://projects.unbit.it/uwsgi/wiki#Wherearethebenchmarks

Слушающиеся размер очереди сообщается о журналах запуска uWSGI.

Но поскольку вы не сообщили о своей конфигурации uWSGI, невозможно дать вам правильный намек.

источник

2011-12-15 07:50:43 roberto

Не существует конфигурации как таковой, я только что установил ее и запустил через командную строку. Он сообщает 100 ограничений на соединение для сокетов, но когда я устанавливаю -l 500, например, получаю тот же результат. В приведенной ссылке упоминается настройка предела очереди ОС - это путь? Я не думаю, что 100 для 16-жильного Nehalem. – Dmitry

Я полагаю, что ваша «нет конфигурации» означает, что вы работаете только с одним процессом. Затем сокет может управлять одновременными соединениями до 101/102. Да, вы должны настроить ядро для увеличения объема памяти, но вам придется работать и с количеством процессов/потоков, а также с тайм-аутами. Что касается отношения 100/16 ядер, вы можете прочитать это http://www.manpagez.com/man/2/listen/, чтобы понять, что такое сокет и как оно работает. – roberto

Спасибо за ссылку. Я выяснил позже, что запуск его без nginx не даст такой производительности. После правильной настройки этого дескриптора он обрабатывает 2000req/s с Django (ну, я могу измерить) – Dmitry

Просто используйте директиву <listen>1024</listen> в конфигурации uWSGI.

источник

2013-09-04 06:36:20

Застрял на 100 запросах uWSGI

ответ

Смежные вопросы