CherryPy 60x медленнее в тесте с 8 запрашивающими потоками по сравнению с 7 - PullRequest
Новая
       6

CherryPy 60x медленнее в тесте с 8 запрашивающими потоками по сравнению с 7

3 голосов
/ 14 февраля 2011

Мне любопытно, почему при тестировании веб-сервера Python CherryPy с использованием ab, с -c 7 (7 одновременных потоков) он может обрабатывать 1500 запросов / с (о чем я и ожидал), но когда Я изменяю на -c 8, он падает до 25 запросов / с. Я использую CherryPy с numthreads = 10 (но это не меняет дело, если я использую numthreads = 8 или 20) на 64-битной Windows-машине с четырьмя ядрами под управлением Python 2.6.

Я наполовину подозреваю, что Python GIL является частью проблемы, но я не знаю, почему это происходит только тогда, когда я получаю до 8 одновременно запрашивающих потоков. На четырехъядерном компьютере я могу ожидать, что он может измениться на -c 4, но это не так.

Я использую однофайловый веб-сервер CherryPy, который поставляется с web.py , и вот приложение WSGI, с которым я тестирую: 

from web.wsgiserver import CherryPyWSGIServer

def application(environ, start_response):
    start_response("200 OK", [("Content-type", "text/plain")])
    return ["Hello World!",]

server = CherryPyWSGIServer(('0.0.0.0', 80), application, numthreads=10)
try:
    server.start()
except KeyboardInterrupt:
    server.stop()

Вывод ab для 7 и 8 одновременных потоков: 

C:\\> ab -n 1000 -c 7 http://localhost/
...
Concurrency Level:      7
Time taken for tests:   0.670 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      130000 bytes
HTML transferred:       12000 bytes
Requests per second:    1492.39 [#/sec] (mean)
Time per request:       4.690 [ms] (mean)
Time per request:       0.670 [ms] (mean, across all concurrent requests)
Transfer rate:          189.46 [Kbytes/sec] received

C:\\> ab -n 1000 -c 8 http://localhost/
...
Concurrency Level:      8
Time taken for tests:   7.169 seconds
Complete requests:      158
Failed requests:        0
Write errors:           0
Total transferred:      20540 bytes
HTML transferred:       1896 bytes
Requests per second:    22.04 [#/sec] (mean)
Time per request:       362.973 [ms] (mean)
Time per request:       45.372 [ms] (mean, across all concurrent requests)
Transfer rate:          2.80 [Kbytes/sec] received

1 Ответ

3 голосов
/ 14 февраля 2011

На моем Linux-компьютере это связано с повторной передачей TCP-пакета из ab, хотя я не совсем уверен, почему: 

No.     Time        Source                Destination           Protocol Info                                                            Delta
  10682 21.218156   127.0.0.1             127.0.0.1             TCP      http-alt > 57246 [SYN, ACK] Seq=0 Ack=0 Win=32768 Len=0 MSS=16396 TSV=17307504 TSER=17306704 WS=6 21.218156
  10683 21.218205   127.0.0.1             127.0.0.1             TCP      57246 > http-alt [ACK] Seq=82 Ack=1 Win=513 Len=0 TSV=17307504 TSER=17307504 SLE=0 SRE=1 0.000049
  10701 29.306438   127.0.0.1             127.0.0.1             HTTP     [TCP Retransmission] GET / HTTP/1.0                             8.088233
  10703 29.306536   127.0.0.1             127.0.0.1             TCP      http-alt > 57246 [ACK] Seq=1 Ack=82 Win=512 Len=0 TSV=17309526 TSER=17309526 0.000098
  10704 29.308555   127.0.0.1             127.0.0.1             TCP      [TCP segment of a reassembled PDU]                              0.002019
  10705 29.308628   127.0.0.1             127.0.0.1             TCP      57246 > http-alt [ACK] Seq=82 Ack=107 Win=513 Len=0 TSV=17309526 TSER=17309526 0.000073
  10707 29.309718   127.0.0.1             127.0.0.1             TCP      [TCP segment of a reassembled PDU]                              0.001090
  10708 29.309754   127.0.0.1             127.0.0.1             TCP      57246 > http-alt [ACK] Seq=82 Ack=119 Win=513 Len=0 TSV=17309526 TSER=17309526 0.000036
  10710 29.309992   127.0.0.1             127.0.0.1             HTTP     HTTP/1.1 200 OK  (text/plain)                                   0.000238
  10711 29.310572   127.0.0.1             127.0.0.1             TCP      57246 > http-alt [FIN, ACK] Seq=82 Ack=120 Win=513 Len=0 TSV=17309527 TSER=17309526 0.000580
  10712 29.310661   127.0.0.1             127.0.0.1             TCP      http-alt > 57246 [ACK] Seq=120 Ack=83 Win=512 Len=0 TSV=17309527 TSER=17309527 0.000089

Оригинальный пакет "GET" не был выбранот Wireshark либо.По какой-то причине ab пытается отправить запрос и терпит неудачу, даже если соединение TCP было двойным ACk, и это нормально.Затем стек TCP клиента ждет несколько секунд, пока пакет, который никогда не отправлялся, будет ACK'd, и когда он не видит ACK, повторяет попытку и завершается успешно.

Лично я не стал бы беспокоиться об этом.Если есть проблема, это не одна с CherryPy.Это может быть связано с внутренними компонентами ab, использованием HTTP / 1.0 вместо 1.1, отсутствием поддержки активности, использованием localhost вместо реального сокета (который имитирует некоторые реалии сетевого трафика и игнорирует другие),использование Windows (подмигивание), другой трафик на том же интерфейсе, загрузка на процессоре ... список можно продолжать и продолжать.

...