Alois Reitbauer About the Author

How to Find Invisible Performance Problems

In the first post for this year, I will discuss an interesting question: “How to find invisible performance problems”.

What makes up an invisible performance problem? An invisible performance problem is an inherent problem in your code, which does not yet manifest in externally observable problems like slow response times, high CPU load or the like. These problems are very often scalability problems. The major point with those problems is that they are normally discovered relatively late in the development process as they are not externally observable.

We all know that the cost for solving a problem increases the later it is discovered in the process.  So the question is now, how do we find something we do not see – or putting it another way round what kind of information do we need to find these problems.

Response times definitely do not help here. We need to observe runtime characteristics which may result in performance problems.  From my experience the major problems that can be discovered without putting load on a system are :

  • Excessive database calls
  • Excessive remoting calls
  • Large amount of data transferred

dynaTrace provides specific analysis features to discover these kinds of problems.  Using PurePath-based analysis each integration test can be analyzed regarding this runtime characteristics. For automation purposes it has also proven useful to define rules checking problematic application behaviour automatically.  The figure below shows the database calls of a specific use case. In this case we immediately see a problem with the data loading strategy.

Massive Database Calls for an Integration Test

Massive Database Calls for an Integration Test

We refer to this process as Dynamic Architecture Validation. It helps to understand the dynamics of code execution and using a transactional view it also allows to understand the context of a transaction like shown below.

Transactional View on Application Dynamics

Transactional View on Application Dynamics

Conclusion

Some problems which can get hard to fix may stay long undiscovered in the application development process. Dynamic Architecture Validation helps to identify them long before they manifest in performance and scalability issues.  While not all problems can be found that way, some of the major problems causing bad performance can be found this way. Additionally this analysis takes you only a couple of minutes and save a lot of time later on.

Comments

  1. Hello,

    Please add your site at http://www.sweebs.com. Sweebs.com is a place where other people can find you among the best sites on the internet!
    Its just started and we are collecting the best found on the net! We will be delighted to have you in the sweebs listings.

    Regards
    Kris

  2. Well,it often happens that people with good eyesight fail to see what is right in front of them.They have too much to observe,I suppose,whereas those who cannot see take in what registers most telling on their remaining senses.

  3. We have too much time talking about love, there links of london charms is too little time in the feelings of love, even love of the often links of london bracelet overlooked on some “gratitude. pandora charms wholesale” If you have Pandora,

  4. TV Weekly described the budding actress, links of london rings came to Hong Kong from Suzhou, Carrie Underwood, at first as not good CantoneseTraining can not enter the artists, but
    links of london she is still learning, after all the success!

  5. It’s interesting to see this occurring for other people.

    We had a similar problem a while ago where some users reported an issue with speed that we weren’t able to track down. We checked the database locking, the inter-process comms and even followed a few false positives (like all the users seemed to be viewing DVDs or Books).

    In the end we found out the common item was that a user was opening a bunch of pages at the same time. This allowed us to track it down to the price comparison code – which was checking the user’s (shared) session state and locking it.

    It’s probably a really good example of why user performance reports need lots of information (which is hard for non-techies to do). Luckily we get a lot of techies browsing for cheap computing / IT books so some of the reporters were really helpful.

    Norris – http://ewelike.com

  6. i think you have taken this new feature in a wrong way , it has its plus points too , for example from a marketer point of view you will get much better results from paid advertising as in google adwords you will be able to focus to individual who are really looking for your products hence each click through will deliver more results because then the user demographics can be leveraged.

Trackbacks

  1. [...] 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 [...]

  2. [...] Validation is not sticking to response times but dynamic application behavior. As I explained in an earlier post the dynamic behavior of the application unveils potential performance problems already before they [...]

  3. [...] Further Reads: Tracing Intermittent Errors by Lucy Monahan from Novell, How to find invisible performance problems [...]

Comments

*


− 6 = three