Ax2 is turning into a pretty sweet pure perl httpd (whether you want XML processing or not).
I've been working a bit this week on a couple of things - getting the uri_to_filename translation working correctly (thanks to Jörg for a lot of work there) according to how Apache works, and then lots on performance and stability.
It serves about 500 requests/second here on localhost transfers (benchmarking locally with apachebench) with a 2K file. That's not very impressive, but then most httpds don't really hit their maximum requests-per-second transfers anyway - they are bottlenecked by numbers of connections and the speed of the network.
So in testing large files, the throughput causes apachebench to overflow integers. It does about 110MB/sec throughput. That's enough throughput to saturate even the fattest of pipes (well ok, it won't saturate an OC48, but if you're doing that much throughput you can probably afford another box!).
This sort of throughput is achieved using AIO. All the stat()s and open() calls are asynchronous (using the excellent IO::AIO) when I'm doing this benchmark.
Now in theory I could build a faster httpd if I just removed a lot of overhead (logging, and all the nice hooks) but those things are worth having. It has hooks like apache has for uri_translation, auth, fixup, etc, making web app development very simple.
As a long time mod_perl user (I realised I've been using mod_perl for 8 years! yikes) I value its flexibility but always thought things could be a bit simpler. And I find Ax2 simpler to develop for. Partly that's the "I wrote it" factor, but it's so much easier to stop and start with "ctrl-c", then "./axkit" than it ever was to do that via "apachectl stop; sleep 5; apachectl start"... and make test starts the server much faster than Apache::Test can (because we can hook right into the module). Debugging can be done with perl -d axkit. Profiling with perl -MDevel::Profiler axkit. Lots of niceties for those developing web apps.
Now how can I get the Jifty and Catalyst communities interested in using this as their primary web server?
Re:Getting Jifty
Matts on 2006-08-26T00:08:26
A "bit" early for a commit bit *grin*. I've never done any Jifty so I'd probably want some sort of example app to play with to make sure it all works.Re:Getting Jifty
jesse on 2006-08-28T00:03:31
We've got a few of those, though you might need to port Test::HTTP::Server::Simple to deal with your server nicely.
You can get jifty-trunk at: http://svn.jifty.org/svn/jifty.org/jifty/trunk
Wifty is a demo-app wiki:
http://svn.jifty.org/svn/jifty.org/wifty/trunk
Re:Apache emulation
Matts on 2006-08-26T14:53:11
Yes, there's a possibility of doing something a bit like that. Though I don't want to get people's hopes up that the Apache API will be fully implemented as some of it simply won't fit (I don't think).
This is also basically how the SAWA plugin works - it fakes up an Apache::Request-a-like and passes it in.
Re:Pointer to the Code?
Matts on 2006-08-26T14:54:08
http://trac.axkit.org/axkit2 to browse via trac.
svn://axkit.org/axkit2 to download
(it's on CPAN too, but there have been lots of changes since then)
Re:DBI
Matts on 2006-08-26T22:41:00
Potentially. I'm not totally set on how to handle DB queries yet - my guess is that with sufficient caching in place it won't matter (and for the places building solutions where they don't care to cache, it probably doesn't matter anyway).
But yes, likely some sort of separate process we can marshal requests to/from. I'd like to make it as transparent as possible, so what I might do is implement a DBD driver that does this natively.Re:DBI
perrin on 2006-08-26T22:49:32
How about things that are not I/O-bound but just compute intensive? Will you do some kind of cooperative time-slicing system similar to what POE does?Re:DBI
Matts on 2006-08-26T22:56:50
For that I am writing a class that forks off and sends the response back when ready. If compute intensive is very common I suggest just using a CGI (which we support already).Re:DBI
Alias on 2006-08-30T20:43:03
If you could have whatever it is able to support working with the Process.pm API, that would be nice.
Re:Can it be Abstracted from the XML Stuff?
Matts on 2006-08-26T22:30:05
Yes. The xmlresponse is already mostly optional. It loads it, and so loads XML::LibXML, but you don't have to implement that phase. I'm sure I could figure out a way to make it entirely optional (or even load XML::LibXML at runtime).
Of course why you would want a web server without XML::LibXML installed is beyond me;-) Re:Can it be Abstracted from the XML Stuff?
Theory on 2006-08-27T18:57:50
That would rock. I was thinking about using it with Bricolage, for example, where we don't do anything with XML.
My thought is that it'd be cool if it was a Web server that supports plugins and nothing but a Web server that supports plugins.
Oh, another q: Would it be possible to allow plugins to be CPAN modules, and then we can just tell the Web server to use a CPAN module as the plugin for a particular Location.
—TheoryRe:Can it be Abstracted from the XML Stuff?
Matts on 2006-08-27T22:47:57
That already works.
Just do:
Plugin Foo::Bar
and it loads it from @INC if the plugin name contains '::'.Re:Can it be Abstracted from the XML Stuff?
Theory on 2006-08-28T17:07:45
Sweet, thanks!
—Theory
