http://laurentszyster.be/blog/naive-benchmarks/

Thanks for reading,

>20 request/sec for CherryPy in the same contexts? Voodoo magic

CherryPy is benchmarked at 234 request per seconds (rps) by william-os4y. But what page is exactly produced? “Hello World” or something as static.

Those Voodoo 20 rps mean 50ms per request.

In a CGI you’ll have to factor in the all time spent serializing the template, plus the wait state introduced by synchronous SQL database transactions, the usual application case, plus module imports, plus the interpreter slow startup and finally the job Apache does to synchronize all that with HTTP/1.1 and other modules.

So, with a standard CGI configuration of Apache and something else than “Hello World” for CherryPy, you can reach 50ms per request with any LAMP framework.

Load an interpreter, import a few modules, connect to a database and make two queries, do some math, transform and serialize the result for presentation: there you are a few tens of milliseconds have elapsed.

Regards,

I am puzzled.

Factoring out the difference between CPU alone, I’m quite happy with the figures. And, indeed, there is a performance gain made possible by an asynchronous design vs. a synchronous one, specially when considering statefull application servers.

That’s why Medusa was called “for High Performance” …

Speaking of async vs. sync, here is a telling benchmark:

http://william-os4y.livejournal.com/1454.html

> Presumably that’s pushable higher by using ePoll

I’m not yet there, but if you *need* speed, investigate libevent’s Python bindings. They are available on both Linux and Windows.

By the way, there’s a little web server in Python called apricot that uses libevent:

http://jamwt.com/downloads/apricot/apricot-0.2.tar.gz

Regards,

>> which OS
Ubuntu dapper

>> how the test was run
ab2 -c 200 http://localhost

Of course such a tiny specific webserver doing out of memory strings only is of little practical use. However, if you compare it to the like 20 request/second cherrypy usually manages, to the 50-100 Apache/IIS can handle, it’s a nice number. Presumably that’s pushable higher by using ePoll (*not* poll), though modules for this in python are not quite forthcomming.

>> What do you think of async_client.py?
Hm hard to say. I’d probably have to try it out to see weather I like it or not. With some likelyhood that’s going to happen somewhen ^^ (next time I need to write network stuff myself)

Nice to have you back in the interesting section of this blog (the one about Allegra’s sources ;-)

> Hm okay, so have you written a small test webserver that returns some static string upon every request and measured performance?

Not quite. There’s a little bit more than that to:

http://svn.berlios.de/svnroot/repos/allegra/lib/presto_http.py

althought it’s far from ready for publication.

> To forgo random guessing, I did write an asynchronous webserver in plain socket/select and it manages 3000 connections/second flawlessly. I’m interested how your framework holds up against such little hacks.

3K connections per seconds? Indeed that’s fast, though it would be usefull to know on which CPU, under which OS and how the test was run. If you care to benchmark Allegra’s web server, you should check out its sources and run those tests.

My own informal tests with Apache’s ab measured PRESTo web server handling around 1ms per requests for the simplest dynamic pages (which are quite close to a static string), running both the test client(s) and the server on the same 1.7Ghz Windoze laptop.

But we’re drifting from the subject of this article.

What do you think of async_client.py?

Thanks for reading,

To forgo random guessing, I did write an asynchronous webserver in plain socket/select and it manages 3000 connections/second flawlessly. I’m interested how your framework holds up against such little hacks.