Caching is not a silver bullet


Let us take a this hypothetical situation. You have to serve a web page. You want the whole page to be sent back in 500 ms (milliseconds). If your user has a good network and he is not too far from your webserver, you can further assume that around 50 ms will be spent on the network. This means that you have 450 ms to collect all the data about this web request, do the fancy manipulations (sorting/filtering/updating files etc.) and serve it to the user. You need to make four external calls to get this data - 2 of them to an external web service and 2 of them to your own database.

Now assume that one of your external webservice calls take one second to send back the result 50% of the time and one of your database queries can take upto a second to give back the result 25% of the time. What will you do to make sure none of your users ever have to wait for more than 500 ms to get back the page? (500 ms excludes the time taken to download the images/css/do fancy javascript magic).


Why MySQL rocks for Web 2.0 startups

Or how your startup can scale up with MySQL


An analysis of the X- headers in my spam

An analysis of the x-headers in spam mails


Creating complex queries in your web form

This article shows a nifty (I hope) way to make the logic part of your webform cleaner.


Playing with your blog's xml-rpc interface

Serendipity provides an xml-rpc interface which you can to edit/update/query your blog using either the MT or the Blogger APIs. Editors like perfomancing, ecto use the xml-rpc interface to post entries to your blog. This article explores the xml-rpc interface provided by Serendipity.


Additional information