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.
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.
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.
trunk/ just got support Linux Native AIO.
You might wonder why it takes to long to release 1.5.0 when most of it is already in trunk.
At MySQL we are in the final strokes of getting a GA release of Monitoring and Advisoring Service of MySQL Enterprise out of the door.
I’m still monitoring the IRC channel, but all development time is going into my MySQL stuff right now.
Back in the times of the first implementations of mod-cml I took the request setup costs as the root of all evil. They were the problem I wanted to fix with mod-cml.
But what is the request setup cost ? What is influencing the request-time ? Where can you influence it ?
darix just moved the svn-trees around. Now trunk/ is containing the code for 1.5.0 (formerly known as branches/lighttpd-merge-1.4.x) and branches/lighttpd-1.4.x is taking care of the 1.4.x series (formerly branches/lighttpd-1.4.11-ssl-fixes).
r1352 got commited to the 1.4.x-branch to fix a crash in 1.4.12.
Over the last evenings I helped several lighty users to tune their application stack. Instead of telling the same story over and over again I wrote it down into a wiki page:
https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_PerformanceFastCGI
Over time this will be the main source for application tuning, hints and secrets.