Performance Antipatterns – Part 1

Last year december I gave a talkat DeVoxx on Performance Antipatterns.  Some people asked me to make avaiable the contents of my talk. Instead of publishing the slides I decided to write a couple of blog entries on the contents of my talk.

In the first entry I will start with some general perceptions on people and performance.  I have found these perceptions in many situations. Most of them see performance management as a very difficult task. I do not believe that.  In most cases it only gets complicate because people take the wrong approach to performance management. I believe that performance management can be done quite effectively if you have a solid approach towards it.

Conception #1 : Good developers write well performing code

I very often see developers with the attitude than it is ok to have functional bugs. Therefore we are writing tests. However it is not OK to have performance or scalability issues in your code.  A good programmer simply writes well performing code.

The reality however is, that performance and scalability very often – if not always – is harder to achieve than correct functionality. Especially with the user of frameworks or components other people have written, you easily run into problems by not using them in an optimal way.  Additionally performance is a moving target, it depends on much more factors than functionality. A change in your deployment or the user behavior will lead to completely different performance characteristics.

The consequence therefore most be to spend at least as much effort on performance management than on ensuring functional compliance. In an earlier post introduced the concept of Performance Regression Testing and Architecture Validation and showed how dynatrace can be used for this purpose.

So to sum it up, good developers write well performing code, because the test and validate performance characteristics instead of thinking they come for free.

Conception #2 : Performance Management is Difficult

Very often I find people thinking of performance management like it were rocket science. They are afraid of performance problems and want to ignore them as long as possible. It is like not going to the dentist just because you expect that you might get a treatment that hurts.

In fact if you care early on you wont run into this problems. In many situations performance management gets difficult for two reasons.

First nobody cared early on and problems are found at the latest possible time when the application is already in production.  The the problems have to be fixed as fast as possible and you are in a stress situation where everybody is looking over your shoulders and expects you to find and fix the problem in the next ten seconds. While production diagnosis can be really help there, the root of the problem is a different one. If you would have cared earlier on you would not even be in that situation.

Second if you want for performance problems to manifest, there won’t be one single problem,  but a lot of small ones influencing each other. This makes analysis very complex as many small and big problems interfere with each other. The symptoms will get very difficult to analyze and you really have a tough job to do. Again if you would have resolved those that you can find earlier, you would be confronted only with the one that did not manifest before.

So to sum it up. Performance problems are definitely not the easiest ones to solve. On the other hand it is a manageable task if you fight face-to-face against one of them. If you wait until your opponent is an army of problems you might end giving up.

Conception #3 – Performance characteristics move – people don’t

Managing performance is more challenging than managing functional requirements. If you have your functionality running in development you can expect it to work well also in production. Performance is much more volatile to the environment.  Changing load characteristics, different hardware, large data volumes, different deployment all affect the performance characteristics of your application.

Still people think if the have tested for performance once, everything is fine. They very often hope that there will not be problems in the future are they are not there now. So they do not invest in continuously managing performance.  If have not only once heard from a prospect: “Thank you for solving the problem.  However we won’t do more right now as everything is working fine. We will come back to you, when we have the next problems”.

My question then always is: “Why not pro actively manage performance and avoid the next problem by seeing the trend before it becomes a problem?”.  You think this is complicated and involves a lot of work. Working for a performance management company, I can tell you it is not. Dynatrace for example automates most of these tasks and informs you on time about potential problems. There are proper approaches for development, testing and production environments.

So like the wise master in a kung fu movie would say: “If you want to hit a moving target, move as well, or you will get hit”

Alois is Chief Technology Strategist of Dynatrace. He is fanatic about monitoring, DevOps and application performance. He spent most of his professional career in building monitoring tools and speeding up applications. He is a regular conference speaker, blogger, book author and Sushi maniac.