webpy performance comparison round 2

general = { about, articles, links, projects }     meta = { date-posted: 2006-04-06 }

As an addendum to my previous entry on Webpy performance comparison, I ran the same tests using scgi.

Here are the results with scgi for web.py.

On a test machine, I get the following results with lighttpd, using scgi with 3 processes python listening on the loopback interface. All tests were with the same "hello world" app that was tested in the last round. ab was again run over a nearly unused network:
ab -q -c 10 -n 1000

With ab -kq -c 10 -n 1000 (keepalives)

Some thoughts:
I found that rails performed better with lighttpd and fastcgi. I have attributed this to the fact that I was using scgi via a loopback port, instead of a socket. I was using the easy to use scgi_cluster program, found here. I wasn't able to easily figure out how to get the scgi_cluster program to fireoff a bunch of sockets instead of binding to ports. My test is simple anyway, and is more of a test of how web.py can be scaled, then it is of how it compares directly to rails.

As for web.py over scgi. Again, I didn't discover easily how to use a socket with web.py scgi. If I was able to, I would likely see some additional performance improvement.

Other things to note:
scgi with lighttpd for web.py seems to do much better load balancing between the three web.py scgi processes I started. The bonus of using the ip+port combination instead of a socket is the ease with which you can move your scgi instances off the lighttpd box. You could easily run a few machines behind a lighttpd webserver, and have extrememly fast backend web.py rendering.