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.
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.
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.
Related posts:
- Performance Management in Continuous Integration I recently gave presentations on Performance Management as part of...
- Performance vs. Scalability When people talk about performance and scalability they very often...
- Tracing problems in Project Stonehenge and other heterogeneous systems In my previous blog post I discussed that interoperability...
- SharePoint: Identifying memory problems introduced by custom code SharePoint is a great platform that makes it easy to...
- Performance Analysis: How to identify “bad” methods messing up the GC Whenever the Garbage Collector kicks in to free up memory...


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