views:

62

answers:

1

Does anyone out there run the profiler on thier ASP.NET web page when running locally. I guess it is like a poor mans load tester.

The tier interactions seems to be the only real usesful part since that show all the queries made and that is normally the bottleneck in a ASP.NET app... There are alot of other options though... Anyone out there using this can tell me what they are using and how useful they find profiling?

Also, can you do CODE COVERAGE on a profiling session ? It seems CODE COVERAGE is only for 'tests' ?

+1  A: 

As you noted, Tier Interaction Profiling (TIP) gives you more detailed information about calls to databases, right down to the SQL statements For more information refer to the Profiler Blog.

Another recommended option when profiling ASP.NET is to profile using Instrumentation Mode. This profiling method shows statistics like function call counts and the time to execute each function (including time spent blocked waiting for I/O etc.).

This is particularly useful if you are making synchronous calls to a database or doing a lot of file or network I/O, since you can detect the calling methods and consider optimizing them.

If you happen to have some ASP.NET code that is CPU intensive, you can also consider using the Sampling profiling mode. This allows you to detect functions that use significant amounts of CPU, although this is less typical in ASP.NET applications.

Since you're using Visual Studio 2010, you might also consider doing load tests on a remote server with profiling enabled. For more information refer to MSDN.

Colin Thomsen
Still can't get code coverage to work with profiling... Some one pointed me to a way to do it on command line but I had no luck... something to do with instrumenting the DLLs.. but my web site had many DLLs so I was confused.
punkouter
punkouter, are you attempting to collect code coverage information (i.e. the percentage of your code executed when running unit tests) or you more interested in function timings? If you are interested in function timings, you should look at 'Instrumentation' instead of code coverage.
Colin Thomsen