When we talk about “improving performance” we’re referring to things like greater throughput, more concurrent users served, improved responsiveness. Putting aside blue pills and nasal delivery systems, scaling application development is after much the same thing. When it comes to web applications, delivering your message as fast as you can leads to greater user satisfaction.
There’s a lot of bits that come together to assemble your humble web page: HTML, CSS, images, Javascript and more. Add to that the transmission time from host to client and it all starts to add up. But lets focus for a moment on just getting the page off the server. Even if you’re serving up pages to only a handful of users a day, improving the responsiveness — the sheer speed — of your application can make a significant impact on the overall “feel”.
Note, “feel” is that un-quantifiable quotient of joy (or un-joy) users experience when interacting with your code.
For dynamic pages such as ColdFusion, ASP.NET, and PHP, simple queuing theory suggests a tipping point at around about 250ms per page. If you can get your page clear of the server in under 250ms you really start to make a difference. Get it down to 50ms and the whole “exponential” thing starts to really kick in.
Efforts to improve performance often centre around bigger “iron” — throw enough hardware at the problem and magic happens. And funnily enough you’ll often find the cost of servers these days is cheaper than the cost of good development. Alternatively, folks obsess about the speed of arrays versus string manipulation and other such miscellany. But trying to wring every drop of speed out of code execution can lead to all kinds of unpleasant compromises.
Take a load off! That’s what I say.
Look at the problem side on. Maybe you don’t need to go faster, but to go in another direction entirely:
- Do as little work as possible for user driven requests
- Do all the work before or after the request
And with that cryptic conclusion, I’ll leave it there for tonight.