Woken up far too early and having the first coffee I shared some ideas on how this could be useful to accelerate AJAX based applications.
Half a year ago I was traveling a bit and tried to get lighty to compile natively on win32
Some time has passed and I concentrated on the other stuff in the 1.5.0 tree, leaving the nasty win32 code in place for someone to pick up. Ben Harper aka rogojin has picked it up and released a win32 installer for the latest pre-release
A simple tests shows that staticfiles are working nicely and that http-proxying with mod-proxy-core works too. Nice work, Ben.
Robert Jakabosky fixed and improved mod-proxy-core alot since the last pre-release:
- fixed unix-socket support
- added AJP13 and SCGI support
- fixed some nasty bugs
- added documentation
- added X-LIGHTTPD-send-temp-file
POSIX Async IO
I added native support for POSIX AIO which might bring async io for more platforms. While Linux AIO is pretty stable the POSIX aio support is pretty experimental. Perhaps it compiles for you.
I tried to compile it on Linux and FreeBSD.
server.network-backend = "posix-aio"
Check if it compiles and works for you.
While I was throwing away from bogus data-copy operations from the mod-proxy-core code I stumbled over a simple question:
Why do we copy the HTTP response data from the backends at all ?
We are just forwarding them in most cases without touching them.
Some time ago we got a request on how to implement COMET with lighttpd. I responded with a idea about a mod_multiplex which would allow the let the client open a COMET-channel and give the backend the possibility to feed multiple channels at once with the client to poll for new data.
Thanks to brave testers in #lighttpd the AIO-support is stabilizing very well and the corruptions that have been reported are fixed now.
Next to bugfixes, I implemented chunk-stealing and doubled the performance of aio for small files (100k) [16MByte/s instead of 9MByte/s].
Before you jump around and empty a barrel of beer, try to compile it first. :)
mod-proxy-core has 3 different balancers for different needs. Round Robin, Shortest Queue First and CARP.
The benchmarks only showed results for small files (100kbyte). Time to add larger files to the pool and talk about the chunk-size.
1.5.0 will be a big win for all users. It will be more flexible in the handling and will have huge improvement for static files thanks to async io.
The following benchmarks shows a increase of 80% for the new linux-aio-sendfile backend compared the classic linux-sendfile one.