Since we've been on slicehost, I've been forced to play the role of system administrator since we don't have a real one. One problem I've run into is the long string of legacy applications that I have to support. Some of them I wrote, and some of them I inherited. For many reasons, they're often organized and run in sub-optimal ways.

Separating your static and dynamic content is a good habit to get into when you're building scalable web applications. Static content is highly portable because it can live without context. You can serve it from anywhere and nobody knows the difference. When your site starts to get huge traffic, you can easily offload your static content to a CDN if you host it in an easy-to-separate way using an URL like static.domain.com or domain.com/static.

Movable Type 4.2 introduced (among other things) built-in pagination. When you have a set of entries published to a dynamic index, you can auto-paginate them with some magical tags and it works wonderfully. That is, it works unless you wanted to use Movable Type's built-in caching system for dynamic content. Movable Type's cache entries are unique to a given relative URL excluding the request parameters. In the case of pagination, request parameters make all the difference on what should be cached.

I was investigating some web site slowness for a friend the other day. His company uses SugarCRM over https. He had been complaining about slowness for over a year and I finally decided to give it a thorough look. Since the sugar application makes heavy use of its database backend, I decided to start there. Unfortunately mySQL's slow query log turned up nothing, except that the database was running about as fast as you could possibly expect with the whole database buffered in memory. I honestly didn't think to check the web server itself because I've never really had a measurable problem with that before, default web server settings have always suited me fine in the past. Apparently all bets are off when running under SSL...