PSGI/Plack: Now we feel like writing real web servers!

Continuous hacking!

Daisuke Murase made FastCGI backend for Plack!

I noticed some issues with PATH_INFO tests when testing with FastCGI and lighttpd. So here's my investigation how they handle them differently. It's a mess. More contributions welcome.

We did some benchmarking with running Catalyst natively with Catalyst::Engine::Apache2 and with Catalyst::Engine::PSGI + Plack::Impl::Apache2. The benchmark shows the number is roughly the same, which proves that PSGI decoupling and abstraction doesn't slow things down, and of course, could be optimized further because of this low level nature, which is awesome.

Randy J. Ray is blogging about HTTP parsers with Perl (and XS).

Kazuho's been working on adding keep-alive support to the standalone server: the apache bench now shows 4000 req/s with -k option! He is now working on the standalone prefork server.

We've found bugs and made patches against IO::AIO to support sendfile(2) in FreeBSD and Mac OS X.

Kazuho pointed out that Impl::Standalone and Impl::AnyEvent code might have a problem with bigger file (like ~2MB) and voila! We added that to the unit tests and it revealed a bug, which was immediately fixed.

tokuhirom made FastCGI protocol client in pure perl. This might not really matter in PSGI/Plack frameworks but would be useful to test our server side implementations, as well as implementing FastCGI connector for perlbal.

Yappo pointed out benchmarking Hello World running on HTTP::Engine::Interface::ServerSimple and Hello World running on Plack::Impl::ServerSimple show almost the same result. It seems true, so "HTTP::Engine is slow because of Request/Response objects creation" feels like a myth. HTTP::Engine is still slower than the native Hello World raw PSGI app, but the overhead doesn't really matter when your web application takes more than 0.01s to serve your page.

I made Sledge::Pages::PSGI plugin to turn your Sledge web app to run on top of PSGI stack for my friends who use the web application framework I wrote 7 years ago :) You need a patched CGI.pm from my fork.

We'll show more numbers once everything gets stable, but so far the number seems promising and very interesting. Simple Hello World is now 4000 req/s with Standalone server with keep-alive on, and 2MB photo file serving runs fastest on AnyEvent server (300 req/s) with sendfile(2) and AIO enabled while other dumb implementation suffers from I/O in the perl land like (80 req/s).

Comments

[Jesse Vincent]

You forgot to add that you found and fixed bugs in HTTP::Server::Simple while working on this ;)

[Stevan Little]

Wow, this is nothing short of awesome. A big ++ to the entire PSGI/Plack team!

[Clayton Scott]

This is great. Those numbers are very comparable to the numbers being quoted in the Python uproar over Friendfeed.com implementing their own python web server.

http://antoniocangiano.com/2009/09/13/benchmarking-tornado-vs-twisted-web-vs-tornado-on-twisted/

[Sid Burn]

The first question that come into my mind was: What the hell is "PSGI/Plack"? Can someone describe it in detail what it is, and which benefits i get from it?

Searching for PSGI/Plack i came across the github repository. In the lib it says it is something like Rack under Ruby.

Nice, waht is Rack?

[miyagawa]

Sid, this FAQ should be helpful.
http://github.com/miyagawa/psgi-specs/blob/master/FAQ.pod

[justin]

adding my comment because this is the first hit for "plack benchmark": my experience after converting a modperl server to plack using plack:request under starman prefork was trivial requests per second doubled and memory per child was half, and system % usage under load was half as well.

lastly, all the immense config cruft of a modperl server was gone.

[miyagawa]

Great to hear that. Notice this post is almost 1 year old, and we now have pretty fast web server backends like Starman, Stralet and Feersum.