2009-11-23 62 views
3

我有一个基于paste.httpserver的web服务器作为HTTP和WSGI之间的一个分离器。当我使用httperf进行性能测量时,如果每次使用--num-conn启动一个新请求,我可以每秒处理超过1,000个请求。如果我使用--num-call来重新使用连接,那么我每秒获得约11个请求,即速度的1/100。paste.httpserver和HTTP/1.1保持存活下来;使用httperf和ab进行测试

如果我尝试ab,我会得到一个超时。

我的测试是

% ./httperf --server localhost --port 8080 --num-conn 100 
... 
Request rate: 1320.4 req/s (0.8 ms/req) 
... 

% ./httperf --server localhost --port 8080 --num-call 100 
... 
Request rate: 11.2 req/s (89.4 ms/req) 
... 

这里有一个简单的重复性服务器

from paste import httpserver 

def echo_app(environ, start_response): 
    n = 10000 
    start_response("200 Ok", [("Content-Type", "text/plain"), 
           ("Content-Length", str(n))]) 
    return ["*" * n] 

httpserver.serve(echo_app, protocol_version="HTTP/1.1") 

这是一个多线程的服务器,这是很难的个人资料。这里有一个变化,这是单线程:

from paste import httpserver 

class MyHandler(httpserver.WSGIHandler): 
    sys_version = None 
    server_version = "MyServer/0.0" 
    protocol_version = "HTTP/1.1" 

    def log_request(self, *args, **kwargs): 
     pass 


def echo_app(environ, start_response): 
    n = 10000 
    start_response("200 Ok", [("Content-Type", "text/plain"), 
           ("Content-Length", str(n))]) 
    return ["*" * n] 

# WSGIServerBase is single-threaded 
server = httpserver.WSGIServerBase(echo_app, ("localhost", 8080), MyHandler) 
server.handle_request() 

剖析与

% python2.6 -m cProfile -o paste.prof paste_slowdown.py 

%httperf --client=0/1 --server=localhost --port=8080 --uri=/ \ 
    --send-buffer=4096 --recv-buffer=16384 --num-conns=1 --num-calls=500 

击中它,我得到这样

>>> p=pstats.Stats("paste.prof") 
>>> p.strip_dirs().sort_stats("cumulative").print_stats() 
Sun Nov 22 21:31:57 2009 paste.prof 

     109749 function calls in 46.570 CPU seconds 

    Ordered by: cumulative time 

    ncalls tottime percall cumtime percall filename:lineno(function) 
     1 0.000 0.000 46.571 46.571 {execfile} 
     1 0.001 0.001 46.570 46.570 paste_slowdown.py:2(<module>) 
     1 0.000 0.000 46.115 46.115 SocketServer.py:250(handle_request) 
     1 0.000 0.000 44.675 44.675 SocketServer.py:268(_handle_request_noblock) 
     1 0.000 0.000 44.675 44.675 SocketServer.py:301(process_request) 
     1 0.000 0.000 44.675 44.675 SocketServer.py:318(finish_request) 
     1 0.000 0.000 44.675 44.675 SocketServer.py:609(__init__) 
     1 0.000 0.000 44.675 44.675 httpserver.py:456(handle) 
     1 0.001 0.001 44.675 44.675 BaseHTTPServer.py:325(handle) 
     501 0.006 0.000 44.674 0.089 httpserver.py:440(handle_one_request) 
    2001 0.020 0.000 44.383 0.022 socket.py:373(readline) 
     501 44.354 0.089 44.354 0.089 {method 'recv' of '_socket.socket' objects} 
     1 1.440 1.440 1.440 1.440 {select.select} 
     .... 

您可以将配置文件几乎所有的时间都是我一个recv。

我决定保释httpref和我自己写的HTTP/1.1与 - 保活请求和使用的netcat发送:

GET/HTTP/1.1 
Location: localhost 
Connection: Keep-Alive 
Content-Length: 0 

GET/HTTP/1.1 
Location: localhost 
Connection: Keep-Alive 
Content-Length: 0 

... repeat 97 more times, to have 99 keep-alives in total ... 

GET/HTTP/1.1 
Location: localhost 
Connection: Close 
Content-Length: 0 

我与

nc localhost 8080 < ~/src/send_to_paste.txt 

总时间发送对于100个请求是0.03秒,所以它的性能非常好。

这表明的httperf做得不对(但它是一种广泛使用的和受人尊敬的一段代码),所以我想“AB”

% ab -n 100 -k localhost:8080/ 
This is ApacheBench, Version 1.3d <$Revision: 1.73 $> apache-1.3 
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ 
Copyright (c) 2006 The Apache Software Foundation, http://www.apache.org/ 

Benchmarking localhost (be patient)... 
Server timed out 

: Operation now in progress 

插装服务器,它处理一个请求,正在等待第二。

想知道发生了什么?

回答

6

经过一番努力,这似乎是要么Nagle's algorithm或延迟ACK,或它们之间的相互作用。它会消失,如果我做类似的东西

server.socket.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1) 

我是如何追踪它?首先,我安装了socket.py中的每个'recv',以便我能够确定哪个recv正在等待。我会看到11个中有5个recv的延迟了将近200ms。我无法弄清楚为什么有任何延误。然后,我使用Wireshark观看消息,并注意到它实际上是从服务器发送到客户端的延迟。这意味着来自我的客户端的传出消息在TCP层中。

一位朋友提出了这个问题,我搜索了“200ms套接字延迟”,发现了这个问题的描述。

粘贴trac报告位于http://trac.pythonpaste.org/pythonpaste/ticket/392以及修补程序,该修补程序在处理程序使用HTTP/1.1时启用TCP_NODELAY。

+0

我自己学会了这个难题:https://github.com/williame/hellepoll/blob/556a302e690ded6627bd1d87b67aceb6f0592b27/http.cpp#L182 – Will 2011-10-28 09:32:11