2011-02-14 8 views
3

-c 7 (동시 스레드 7 개)과 함께 ab을 사용하여 Python 웹 서버 CherryPy를 벤치마킹 할 때 궁금한 점은 1500 회의 요청/초를 서버로 처리 할 수 ​​있다는 것입니다. ,하지만 -c 8으로 변경하면 25 개의 요청/s로 떨어집니다. 파이썬 2.6을 실행하는 4 개의 코어가있는 64 비트 Windows 컴퓨터에서 numthreads = 10으로 CherryPy를 실행하고 있습니다 (그러나 numthreads = 8 또는 20을 사용하면 다른 것을 만들지 않습니다).CherryPy 60x 8 벤치 마크에서 느린 속도와 비교 8

저는 Python GIL이 문제의 일부라고 의심하고 있습니다.하지만 동시에 8 개까지 동시 스레드를 요청할 때 왜 그런 일이 발생하는지 알지 못합니다. 4 코어 머신에서는 -c 4으로 바뀔 수도 있지만, 그렇지는 않습니다.

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() 

7 개, 8 동시 스레드의 ab 출력은 : 여기 web.py 함께 제공하고, 하나의 파일 CherryPy 웹 서버를 사용하고

내가에 대한 테스트있어 WSGI 응용 프로그램입니다 : 내가 정확히 모르겠어요하지만 내 리눅스 상자에서

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

Linux 상자에서 테스트 한 결과, -c7에서 -c8까지 성능이 조금 떨어지는 것으로 나타났습니다. 대략 (1 초당 1800 ~ 600 ~ 1200 초). 이 문제는 마지막 요청에서 발생하는 것으로 보이며 -n이 10,000으로 업데이트되면 사라집니다. 시도해 보셨습니까? –

+1

감사합니다, Romauld. 네,'-n 10000'으로 정확히 같은 평균값을 얻었습니다. 그리고 마지막 요청에 어떤 차이도없는 것 같습니다. 귀하의 기계에는 몇 개의 코어가 있습니까? –

+0

2 개의 코어가 있습니다. –

답변

3

, 그것은, ab에서 TCP 패킷의 재전송으로 인해 이유 :

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가 전송되지 않은 패킷에 대해 몇 초 동안 대기하고 ACK가 없을 때 재 시도하고 성공합니다.

개인적으로 나는 그것에 대해 걱정하지 않을 것입니다. 문제가있는 경우 CherryPy에서 문제가 발생하지 않습니다. ab의 내부, 1.1 대신에 HTTP/1.0 사용, keepalive의 부재, 실제 소켓 대신 localhost 사용 (네트워크 트래픽의 일부 현실을 시뮬레이션하고 다른 것을 무시함), Windows (윙크), 같은 인터페이스의 다른 트래픽, CPU로드 ... 목록이 계속 켜져 있습니다.