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.
Large Response content
Robert already did some benchmarking and it looks like you the X-LIGHTTPD-send-temp-file helps if you have to send more than 16kbyte of content. Otherwise it fits into one FastCGI packet and into the TCP recv-buffers. Boring, right ? Let’s take the next step and move the idea a bit further.
Pre-generating content
At the railsconf in June Zed Shaw and I discussed on some ways to accelerate rails apps and funky Web2.0 apps in particular.
Usually you have dependencies between components. Let’s say you are writing a mail app and you are pooling the “you got mail” service and want to show a fade-in showing it and in the same way refresh the folder-list to show the new mail-count.
We want to play nice and only load the components which really have changed, so you have 1 to 3 XMLHTTPRequests:
- the “you got mail” fade-in
- if their is new mail, the the folder list gets updated
- if the new mail is in the the current folder, the folder view gets updated too
In the AJAX world you have smaller requests, but all of them have to load the session first, before they can generate their content. What if you turn it around move the above logic back into the server and the “you got mail” loads the session once and generates the content for all 3 parts as it knows that app will ask for it anyway in the next 1-2 seconds ?
It would make the folder-list and the folder-view requests instant, as they just have to check if the content-file exists and can stream it out with X-LIGHTTPD-send-temp-file right away.
Now you just have to mix in some cleanup on mtime in case the temp-file is not fetched [perhaps memcached ?], have to find a way how to guess the filename without reading the session first [that’s the expensive part we want to get rid off], …
Read Ahead
In a way this is like read-ahead on Hard Disks or prefetch in CPUs or even browsers
Hot or not ?
Ok, what do you think about this idea ? Do you have problems that could be solved this way ?