citeulike (![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small} citeulike) wrote,@ 2005-03-21 13:22:00 |
|
Optimisations
I've rewritten a substantial chunk of what goes on behind the scenes on the server. You shouldn't notice any difference except from:
and..
The chances of this all working entirely smoothly are pretty slim, so please let me know if you notice anything untoward happening on the site.
The geeky explanation of what I've done is as follows:
I replaced a simple shared-memory hashtable with memcached together with some modifications to handle dependencies in data as well as a custom Tcl client API.
The advantage of this is that I can pre-cache the HTML rendering of each article in the list (hence I moved the "delete" button so the HTML doesn't depend on whether you're logged in or not), and use memcached's method for fetching multiple objects in one request to simply suck down all the HTML fragments and then simply play them out to the webserver. Not only is this approximately 10 times faster than what I had before (a typical page with all the articles in the cache renders in 12ms), but most of the remaining time is taken up just waiting for the data to appear over the network - and this consumes next to no CPU at all. That means I've managed to get at least an extra factor of ten capacity out of the existing hardware (and there are probably still some more optimisations I can do if I need to), and I can now use multiple instances of memcached to effectively scale up capacity by adding more hardware when required.
So, I'm now in a pretty good position to cope with growth of number of users (which is exponential), and I can now get back to spending more time adding features (like finally writing that API) than worrying about this stuff. The only thing I still need to do, of course, is fix all the bugs which I've just introduced - please do let me know if you notice anything broken.
I've rewritten a substantial chunk of what goes on behind the scenes on the server. You shouldn't notice any difference except from:
- The "delete article" button has moved from the list page to the article page itself.
- If two people post the same article in rapid succession, you only see the latter as opposed to filling the page up with multiple instances of it.
and..
- page generation is 10 times faster than before (for some of the more commonly viewed pages).
The chances of this all working entirely smoothly are pretty slim, so please let me know if you notice anything untoward happening on the site.
The geeky explanation of what I've done is as follows:
I replaced a simple shared-memory hashtable with memcached together with some modifications to handle dependencies in data as well as a custom Tcl client API.
The advantage of this is that I can pre-cache the HTML rendering of each article in the list (hence I moved the "delete" button so the HTML doesn't depend on whether you're logged in or not), and use memcached's method for fetching multiple objects in one request to simply suck down all the HTML fragments and then simply play them out to the webserver. Not only is this approximately 10 times faster than what I had before (a typical page with all the articles in the cache renders in 12ms), but most of the remaining time is taken up just waiting for the data to appear over the network - and this consumes next to no CPU at all. That means I've managed to get at least an extra factor of ten capacity out of the existing hardware (and there are probably still some more optimisations I can do if I need to), and I can now use multiple instances of memcached to effectively scale up capacity by adding more hardware when required.
So, I'm now in a pretty good position to cope with growth of number of users (which is exponential), and I can now get back to spending more time adding features (like finally writing that API) than worrying about this stuff. The only thing I still need to do, of course, is fix all the bugs which I've just introduced - please do let me know if you notice anything broken.
