English: An example of the newly-designed Guinness glass, put into use in April 2010. It was designed to gradually replace the older tulip-shaped glasses. (Photo credit: Wikipedia)

An excited member of my team once came up to me and told me he’d sped up a subsystem by a factor of 700 times. Once he ran some full system tests, we found that the optimisation had absolutely zero performance impact on any observable aspect of the system. The online requests still took the same amount of time. There was an overnight batch that took almost exactly the same time as before we applied the optimisation. The guy was crestfallen.

How many times have you been on the phone to your bank and the operator says something like “Sorry for the delay Sir, the computer’s really slow today”? Performance problems are an annoyance. Unless things are really bad, you can typically use the system, but it’s slow. We human beings are an impatient lot, so the annoyance level of a system taking 5 seconds to respond instead of 1 is higher than you might expect.

There is some mystique about the performance of a system. With good reason. To really understand performance, you need to understand a hell of a lot about the 1s and 0s that are flying around at the lower level. You need an understanding of what’s happening at the hardware level to make sure there are no bottlenecks there. Sometimes it might be the operating system running out of resources or perhaps the database. It might even be the application code itself. A good performance expert will have many years of experience and an intuitive grasp of what’s going on at every level.

It usually boils down to three different types of problem. Either the tasks in the system are taking too long, or there are too many tasks going on or there is contention.

Suppose you have a bar. Suppose that each time the barman serves a customer, he has to go next door and buy a glass. Each customer interaction is going to take a long time. Adding more barmen is the wrong approach. To fix the performance problem, you need to have a shelf full of glasses that the barman can use whenever a customer places an order. You also need to make sure the shelf gets restocked.

Suppose 20 thirsty people turn up. Now, there is contention for the barman. Cutting the amount of time the barman takes to serve each customer will help, but adding more barmen would probably help more.

Suppose 14 coach loads of thirsty Irishmen turn up on the way back from a rugby match. Now you’ve got a real problem. Not only have you got too many customers to serve, and you have contention on the bar staff, the chances are that a good proportion of them are going to order Guinness (the drink that takes the longest time to serve). To add insult to injury, they’ve probably spent all their money at the match so many of them will also be paying by credit card.

In this example, you’ve got multiple examples of all 3 types of problem at once, which is typically how it goes when you are looking at a complex application. So the next time you’re on the phone to the call centre and the system’s slow, cut them some slack. And spare a thought for the poor sod in the back room who’s trying to work out why.

Related articles

• What on Earth is a Taxidermist? (ah69.wordpress.com)
• “The Barman” (dailymobster.wordpress.com)
• Got any bread? (kibworthsnooker.wordpress.com)
• Basic Trouble Shooting Steps for Windows Vista (gethelp247.wordpress.com)
• The Mystery of the Little Big Transaction Time (apmblog.compuware.com)
• Hate your work? Not your fault, because no one ever told you that it is the ‘WHY’ that matters, not the ‘WHAT’. (iamthemorpheus.wordpress.com)
• Script. Drama. Theatre. Performance. (anapereu.wordpress.com)
• Performance optimisations of x86-64 assembly – Alignment and branch prediction (stackoverflow.com)
• ‘What is performance?’ (biancalcassidy.wordpress.com)