lighttpd+web.py的一个简单测试结果:每秒可处理350个请求
先看截图:
我使用ubuntu server 8.04,siege和lighttpd都在这台机器上,也跑着x,并且是跑在vmware下。
longest transaction为2.85秒,看lighttpd的error log大概找了下原因:
2008-06-08 12:15:12: (mod_fastcgi.c.3524) all handlers for /code.py/code.py/ on /code.py are down.
2008-06-08 12:15:15: (mod_fastcgi.c.2655) fcgi-server re-enabled: 0 /tmp/fastcgi.socket
2008-06-08 12:15:17: (mod_fastcgi.c.2882) backend is overloaded; we'll disable it for 2 seconds and send the request to another backend instead: reconnects: 0 load: 162
2008-06-08 12:15:17: (mod_fastcgi.c.3524) all handlers for /code.py/code.py/ on /code.py are down.
2008-06-08 12:15:20: (mod_fastcgi.c.2655) fcgi-server re-enabled: 0 /tmp/fastcgi.socket
这个siege还是第一次使用,由于没有sudo,所以默认的log文件的存放位置就没记录下来。从lighttpd的log上看肯定有500返回的。对web.py也是刚刚接触,还不知道他性能问题在哪。
我使用ubuntu server 8.04,siege和lighttpd都在这台机器上,也跑着x,并且是跑在vmware下。
longest transaction为2.85秒,看lighttpd的error log大概找了下原因:
2008-06-08 12:15:12: (mod_fastcgi.c.3524) all handlers for /code.py/code.py/ on /code.py are down.
2008-06-08 12:15:15: (mod_fastcgi.c.2655) fcgi-server re-enabled: 0 /tmp/fastcgi.socket
2008-06-08 12:15:17: (mod_fastcgi.c.2882) backend is overloaded; we'll disable it for 2 seconds and send the request to another backend instead: reconnects: 0 load: 162
2008-06-08 12:15:17: (mod_fastcgi.c.3524) all handlers for /code.py/code.py/ on /code.py are down.
2008-06-08 12:15:20: (mod_fastcgi.c.2655) fcgi-server re-enabled: 0 /tmp/fastcgi.socket
这个siege还是第一次使用,由于没有sudo,所以默认的log文件的存放位置就没记录下来。从lighttpd的log上看肯定有500返回的。对web.py也是刚刚接触,还不知道他性能问题在哪。