Every time I work with one of our .NET customers to help them with managing their application performance I come across the same problems as seen with other clients before: lots of ADO.NET queries, many hidden exceptions in core or 3rd party .NET libraries, slow 3rd party components, inefficient custom code…

Too often we from dynaTrace are introduced when it is already very late in the development cycle. Most of the time we're introduced when the first performance test results show bad response times and nobody understands why it is that slow. In other cases we get called when there are problems in production and it has already taken too much time to figure out the root cause. Solving these problems at that point can become really expensive as it sometimes involves changes to the architecture. Most of these problems can be prevented by following some basic principles from the start of the project. In this article I cover some of the problems I’ve seen and I encourage everybody to read the paper I wrote on Performance Management for .NET Applications that covers this problem domain in detail.

Why performance problems leave development?

We came a long way of adapting agile development principles which puts a great focus on continuous testing and good test coverage. But still many problems escape development. Here are 3 statements that I regularly hear when developers are confronted with the first load testing results. I am sure they sound familiar to you.

“Our Unit Tests were all green and we executed them on every build”

“Everything ran perfectly fine on my local machine – I even executed some load”

“Everybody on the Online-Forums of the 3rd Party Framework we use seemed to have good experience with performance”

The Status Quo in development however shows the following problems: Unit Tests only verify the functionality but don’t take performance, scalability or architecture into account. Local Performance Tests or either not done at all or with unrealistic sample data. 3rd party frameworks like O/R-Mappers, logging frameworks, … are often used incorrectly for the applied use case scenario. And last but not least – Data Access either from a database or via remoting protocols is often done inefficiently by causing too many roundtrips or requesting more data than needed.

2 Examples of problems that can be prevented

My first example is database access. There are 3 scenarios that I often see

1. The same data is requested multiple times for the same request
2. Data is requested inefficiently, e.g.: multiple SQL calls that could be aggregated into fewer calls
3. More data is queried than actually needed

My recent .NET engagement was on a SharePoint application. SharePoint provides an API to access the data stored in the SharePoint Content Database. I’ve blogged several times about how not to use the SharePoint API but it seems that this problem is still out there. Following screenshot of a PurePath shows that iterating over all items in a SharePoint List actually executes the same SQL statement for every item in the list because the SharePoint API is used incorrectly.

• Diagnosing Tough Performance Problems
• RESCUECOM Issues Annual Top Five Computer Problems Report
• Gomez Unveils Gomez Performance Network 6.5 Featuring First Intelligent Diagnostic Capability for Web Performance Problems