Performance is King… (3)

… but somtimes the jester rules.

This is part three of our little series, see here for part one and part two.

OK, five done, three to go:

If someone complains about performance problems:

6. Don’t deny or fingerpoint. Don’t ignore these concerns, even if unsubstantiated or inappropriate

There is a fact to realize and accept: If you are working on the UI layer of an application, you are likely to be the “face to the customer”. The UI surfaces all features and their characteristics to the user, so the customer will tell you that loading that page takes way to long. Not the database guy. Not the infrastructure people. You!

If the problem is in the UI, there’s no point in denying. If it’s in the adjacent layers, help the people responsible for those areas – but also try to compensate (in case the other guy can’t handle the problem).

The key takeaways of this point should be:
1. Work with the other guys to solve the problem, not against them.
2. At the same time try to mitigate/compensate any shortcommings of the called layer/systems.

What you should not do is: Don’t ignore the customers concerns, even if they are not appropriate (e.g. because the application being tested was an early development build). At least take note of the pain and actively address it later. The customer usually is not interested in who actually caused the problem (even – or rather especially – if it was himself). But it will be you who solved it.

7. Understand the problem.

Is the problem really a performance problem? Or is the customer actuallay aware that the current action takes time and he is just asking for some kind of feedback (e.g. some kind of progress dialog).

Is the customer acting within the specification?
The other day we had a specification for some email distribution function. About 20 emails average. It was perfectly valid to send these emails synchronously and provide instant feedback on success and failure. Then came this power user out of nowhere, sending 5000 emails at once. And in his wake the other real world users, sending 1000 average. Another example would be to use a grid component that does sorting and other gimicks via scripting on the client side – and users that request a result set of 300,000 rows.
These are perfect examples of performance problems that actually are specification issues. They cannot be adressed with profilers, they need design changes.

Key takeaway: Unless you know exactly what the actual demand is, any action taken is futile. The range of possible actions might include classical optimization, design changes, strip down the feature, or even teaching the customer.

After initial deployment:

8. Harden your application.

Eventually your first version will be delivered and the first group of users will begin working, hopefully satisfied. Before starting to work on the next features, take the chance to harden your application against future demands. The number of users will increase, as well as the amount of data in your system. Thus, the fact that your system can handle the current workload accounts for nothing.

Do extensive load testing, especially under stress and abuse conditions (i.e. pull the network cable of the database server). Do this with complex data, real life data, mass data, data out of the specification, and under load test conditions. Verify that the system remains stable under reoccuring error conditions. Have some fun with abuse tests. (Did you know that Porsche tests his cars offroad?)

This way you will learn how much workload your application can handle and how robust it is against unexpected circumstances.

Ouff, finally done. 8)

Now, just for the fun of it, reread this list (including the previous post) and think about what these things will accomplish that is not performance related. Right, nothing of this is purely performance related, some things even barely (in other words, you should be doing them anyway). In other words: Preparing for performance this way will have positive effects on the quality of your application in very different ways, far exceeding simple call time improvement.

PS: This post concludes this little series about preparing for performance in a project. I may have to say something about actually optimizing (you know, the time when you get to use profilers…), yet this was not my intention for now.

That’s all for now folks,
AJ.NET

Advertisement