The end of Guinness

Guinness Pint

Guinness Pint (Photo credit: Stephen Edgar – Netweb)

We discussed it at length and decided that we didn’t want one. We had one at our previous place which disappeared causing us to both be very upset. It was cute, but messy, especially when the woman from the letting agent came around to inspect the place.

The very next day after we made our decision, there was a knock at the door.

My family was outside bearing exactly what we decided we didn’t want, a kitten. It was the tiniest ball of fur you have ever laid eyes on, no bigger than a mouse. Jet black in colour with dainty white feet and a white bib under her chin. Her most distinctive feature was her eyebrows. They were fine, silvery white and arced out high above her head. We fell in love instantly.

“What are we going to call her?” asked my wife.

She offered a few unconvincing kittens names but I wasn’t persuaded. The name needed to fit and as she lay on her back on the floor with her white paws  up, she resembled a miniature pint of Guinness and so she was christened.

We were a bit worried at first because we already had a kitten called Tommy in the house that a friend asked us to look after whilst she was away. Tommy was twice the size of Guinness and was strong-arming her as they played. We needn’t have worried though because what Guinness lacked in size, she made up for in spirit. After they played for a short while, Guinness got the upper hand and from that point on, there was no more bullying.

Guinness was with us for a long time and it’s fair to say she had her fair share of quirks. Like she chose to use the dirt tray that lay just outside the bathroom in a particularly smelly manner when I was relaxing in the bath. She also would choose to noisily slurp out of my cup of water on the bedside table when we were trying to sleep. I used to say to my wife that I would die of some vile horrible cat disease because of the shared cup. She was incredibly good when any children came round, patiently allowing them to tug, prod and poke her with barely any protest.

But after 17 years, we returned to our home to find Guinness very sick indeed in my mother in law’s arms. She wouldn’t eat or drink. She couldn’t walk. We took her to the vets and the news wasn’t good.

Guinness is no more, which is sad. Very sad.

Enhanced by Zemanta

Performance

English: An example of the newly-designed Guin...

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.