Thanks for that long comment. And thanks for publishing apricot and more fine software. I have not read it all, but I found what saw in apricot/httpd to be elegant, simple and very Pythonic indeed.

As you supposed well, I don’t want to go back to Twistedland. So, I won’t comment anymore, I still maintain my critics. Let’s talk about libevent instead.

I like it, but I can’t use it for Allegra.

First, the libevent API does a great job abstracting the different OS asynchronous I/O interfaces. Second, it can handle large number of slow concurrent connections. Third … it is designed for single-purpose high-performances server, not for multiprotocol network peers.

The libevent API for I/O demands that its application register and unregister sockets as beeing writable and/or readable. Which, as you probably allready found out, makes (a lot) more difficult to decouple protocol and transport implementations.

When you face the problem of pipelining and protocol encapsulation, as in HTTP/1.1, not having a dependency on the I/O event loop allows to implement input, output and encapsulated protocols simply and independantly. This is what asynchat.py did so well.

On the contrary, there is a live example of what you must develop on the “fab four” to get a large library to program complex multiprotocol applications. And, in the end, the result performs worse despite the superior performance of the I/O loop itself.

Because *all the rest* is much more complicated, runs more bytecode, instanciate more state and takes more time than was saved.

What I like and what makes apricot-0.2 so fast is its simplicity ;-)

As for the comparison with apricot-0.2 performances on an Opteron 246, I suppose it has a lot to do with the better plateform you used to test it. I used Windows. Linux for instance is much better at disk I/O and filesystem stuf, it will block a lot less often and less longer. This is a critical factor for the performances of an asynchronous web server that serve one file for each request.

Regards,

But yes, apricot is pretty minimalistic. As the notes say, it’s intended more of a proof of concept than a usable HTTP server. I think it proves that concept well: python can certainly be “very fast” (or whatever that means) for many async network applications, given the right set of tools.

I have a 80% complete asyncronous “framework” of sorts based on libevent and my own experiences developing asynchronous network apps on select()/asyncore/twisted/libevent over the last few years. When I eventually release it, it will have an HTTP/1.1 protocol implementation as well.

FWIW: I don’t think twisted is the perfect tool for every async problem, and I think it has its flaws; but it’s robust, mature, and dependable, and I’d say worthy to be the pillar of the python community it is. You don’t always need a swiss army knife (sometimes you just need a very sharp chef’s knife), but when you do, Twisted, in my experience, fits the bill very well. Granted, my experience isn’t necessarily indicative of the common (or “ideal”) one, but I found twisted to be a more productive, dependable, and elegant environment than “raw” asyncore–though the learning curve was certainly much steeper. But it was good learning, IMO. Like or dislike their design idioms, the twisted guys really, *really* know shitloads about async.

Not to attempt to rip you “back into Twistedland” or anything. But as someone else writing an “alternative” async framework, I wanted to present a middle view.

Anyway, thanks for the benchmark post–always interesting.