Strategies for investigating performance of an ASP.NET web application running under .NET 4

Question

I'm trying to compare the performance of an application that has recently been converted from .NET2 to .NET4. From my perfomance tests it seems that although page response times are generally a bit better under .NET4, they are worse than the equivalent under .NET2 when under stress.

From what i've seen so far is that under .NET4, the processor (4 cores) becomes saturated earlier and IIS uses perhaps 20% more threads.

What should I be looking at next to advance in my understanding of what could be causing these differences?

Answer 1

It is hard to say from the level of detail you provide, what exactly is the case. When you are saying

that has recently been converted from .NET2 to .NET4.

this could mean different things: ranging from »The compiler was just a .NET4 compiler and compiled for that target« to »Hey, there are such niceties in terms of Parallel Programming. Let's rewrite everything«

And with the latter in mind, perhaps(!) this is the reason for your observations

they are worse than the equivalent under .NET2 when under stress.

or

From what i've seen so far is that under .NET4, the processor (4 cores) becomes saturated earlier and IIS uses perhaps 20% more threads

But neither have to do with the switch from .NET2 to .NET4 but with obsession of parallelism. There is a nice article from Zeroturnaround for Java-People which were introduced lately to parallel Streams which is equivalent to PLINQ under .Net.

I cite the last paragraph

Parallel streams are unpredictable and complex to use correctly. Almost any use of parallel streams can affect the performance of other unrelated system components in an unpredictable way. I have no doubt that there are people who can manage to use them to their benefit, clearly and correctly. However, I’d think twice before typing stream.parallel() into my code and would look twice when reviewing the code containing it.

Further Strategies

There is only one successful strategy

Measure, Do not guess

Most of the time, when dealing with performance issues, people start to guess »Oh, I know where the bottleneck is: it must be X. I always thought X to be bad design ...« Stop the guessing game and measure. There could be a ton of reasons, of why the performance of an application is slow.

There are several ways/levels of measuring: starting from simple logging of timestamps for some actions up to using tools like Glimpse, New Relic or AppDynamics.

Take what suits your needs/budget. I've worked with AppDynamics for JAVA and it was a great tool.

If you spot the real bottlenecks, you are able to make an informed decision on how the code has to be changed.

Answer 2

On a Win32/Win64 OS, the excellent, open source, ProcessHacker will give you a very fine-grained view of the processes, threads, modules, even managed code assemblies loaded and being executed in any given process tree, along with CPU and memory utilization, including all the sorts of OS handles they use, etc.

'HTH,