DMGOne Page a Second
One day, someone will tell people about stuff you're saying and you want your site to still be there when the people that listen to them turn up on your doorstep.
So I'd be pretty stupid to neglect making the software that runs this blog as fast and stable as possible. In the (admittedly, unlikely) event that I say something smart in public, it would be good if the public heard it.
Earle says, "Daring Fireball gave me about one new visit a second, for over an hour." So that's the metric I'll aim for.
I just checked, and it looks like I'm doing a page about every 1.2 seconds. Way too slow. So I've got work to do.
First, I'll check for obvious software improvements that I can make that will obviate further effort. Maybe I'm making repeat calls to the database, or I've got my transaction settings wrong. Maybe I'm running queries that I don't need to.
So let's say I check, and make the obvious improvements, but I'm still not where I need to be. What next?
Developers, listen up: your instinct is going to be to start implementing object caches, and switching from POJO to EJB data access layers, and... and... and. All of this is wrong. You are solving the wrong problem.
Let's review:
I want to serve one page every second. So once I hit the point of diminishing returns (and believe me, EJB is that point), it's time to reach for the next power tool.
So I'm not going to micro-optimize my loops and whatnot. That's going to take a lot of time I just don't want to spend.
So I'll reach for a bolt-on caching engine. If I do any development at all, it'll be to make sure I'm playing well with the cache. Return codes are easy and pretty quick. Implementing a high-performance HTTP cache is not.
And if that still doesn't work, I'll talk to Akamai. Because I'll have so much traffic I'll be able to monetize like a mofo.