It is a tradition now to change the build-system from lighttpd on each
major release.
For now we have the autotools as the user-visible build-system and
scons as the system for the developers.
Currently we are testing cmake as a replacement for the scons part.
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.
In Faster FastCGI I talked about using temp-files in /dev/shm to reduce the overhead of large FastCGI requests. Robert implemented it right away and it is available in the latest pre-release.
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.
Robert Jakabosky fixed and improved mod-proxy-core alot since the last pre-release:
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.
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.
Basicly it would separate the HTTP Request-Response cycle from the underlying connection. HTTP would be used to open the connection and reopen it in case it went away, but otherwise it would be just a data-channel for your JavaScript/AJAX content we want to send to the client when WE (the content-provider) want.
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).
The benchmarks only showed results for small files (100kbyte). Time to add larger files to the pool and talk about the chunk-size.
mod-proxy-core has 3 different balancers for different needs. Round Robin, Shortest Queue First and CARP.
Yeah, really.
Before you jump around and empty a barrel of beer, try to compile it first. :)