mca blog

a good portion of my job is to cook up server scripts that deliver things list reports from log data, simple read/write UI for configuration files, etc. this usually means i read file data, transform it into acceptable web representations (XML, XHTML, JSON) and ship it back to the client (usually browsers). i do this often enough that i have a pretty well-established coding pattern (once the UI and URI design is done).

get the request/response working

simply put, get the basics of handling the requested URI and sending the right response. get it clean. get it simple. no fancy stuff. once that's working you can move on to more fun.

add compression

this is the first optimization that you can add and it's very easy. in ASP.NET it's about ten lines of code. check out my post on how to do it.

add local caching

this takes a bit more work, but is also fairly easy to do. basically, you need a simple class (CacheObject) with two properties (Payload, ETag). then you use the built-in Cache class in ASP.NET. when you get this working, you can cut down on your CPU load - sometimes quite a bit. i usually cache the resulting text output i send to the client (XML, XHTML, etc.). that means recalling the data from the cache can short-circuit the whole computation loop! i'll post on this later.

support 304/ETags

ok, this takes a bit more work, but is well worth it. instead of reducing CPU load, this reduces bandwidth. by sending the ETag from the cache object (see above) with the response, clients can then send it back the next time they request the page. the server can check the sent tag against the current tag associated with that object and, if they match, just return HTTP 304 (Not Modified) instead of sending data. this is really helpful for large files. i'll work up and example of this sometime soon.

ok, so there it is. a simple pattern to get things up and running quickly *and* optimize the throughput without a lot of rig-a-ma-role.