Faster Web 2.0 3

Posted by jan Tue, 19 Dec 2006 06:47:00 GMT

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:
  1. the “you got mail” fade-in
  2. if their is new mail, the the folder list gets updated
  3. 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 ?
Trackbacks

Use the following link to trackback from your own site:
http://blog.lighttpd.net/articles/trackback/2569

Comments

Leave a response

  1. Paul Annesley Tue, 19 Dec 2006 10:35:26 GMT
    It certainly sounds like a great option to have.

    Of course, most of the performance gain is in the application logic; the prefetching, cheap storage and logic to deliver the cached response on a subsequent request. This can be achieved regardless of the HTTP server.

    Still, it wouldn't hurt to have the option of telling lighttpd to serve the prefetched response straight from memory, and possibly shave off a fraction more latency.

    I think "guessing" filenames of prefetched content to serve up from shared memory would be asking for trouble - especially in shared hosting environments.
  2. Mike Bulman Tue, 19 Dec 2006 14:47:12 GMT
    I'd definitely say "hot". In general I'd agree with Paul that a lot of this should be handled from an application standpoint to keep things server independent, but I think the idea has a ton of potential.
  3. Francois Simond Fri, 22 Dec 2006 10:38:45 GMT

    For Rails, using RJS is probably a easier and faster option.

    With RJS, you can update multiple page elements with only one HTTP (and web application) request.

Comments