… but Kings are not infallible.
Recently I was asked to look into a project because someone presumed the application may have performance problems. Despite the fact that the application was barely functional and they had virtually no real life test data they were worried enough to call me in. This proves again that performance is always a key concern of … well, everybody.
I have been working on very different projects with very different performance demands (ranging from an archive service that needs to be able to handle up to 20 mio messages during business hours, to load balanced web applications, to windows client applications that can use up the whole machine for their purpose). And yet, if it comes to performance they have more in common than one would think.
So, what do you do if a customer complains about poor performance? How do you prepare for this situation? More often than not the answer is like “well, we haven’t been looking into the performance yet…”.
Avoiding that pitfall is easier than one might think, and it doesn’t even take that much effort. Actually most of the concrete suggestions below are not just performance related but also help in other areas.
Here’s some lessons learned that might help:
During design and development:
1. Keep performance in mind. Check your design under performance condiderations.
2. Put measurement points in your code to understand the “performance distribution” (i.e. how much time is spend in which part of the code).
3. Encapsulate areas prone to performance issues.
4. Make sure you have good test data (complex data, usual data, real life data, mass data, invalid data out of the specification).
5. Plan for initial performance tests.
If someone complains about performance problems:
6. Don’t deny or fingerpoint. Don’t ignore these concerns, even if unsubstantiated or inappropriate
7. Understand the problem.
After initial deployment:
8. Harden your application.
Now, theses posts tend to get longer and longer, I’ll therefore split this topic into several parts. Mean, ey? Just like in TV with the advertisment break just before the murder is being resolved ;-). Anyway, I can’t help it, so please bear with me and stay tuned. The next posts will dig into each single point.
Good list of suggestions.
We should introduce performance testing earlier in the Development cycle.
Also, We should keep good test data (point 4) ready during daily builds to keep performance problems at bay in later stages.
Comment by Ashith Raj — February 16, 2007 @ 1:47 pm