Profiling ASP.NET apps with the help of external load and web tests

ASP.NET profiling in Beta 2 from within the IDE opens up an IE browser window as if you were going to generate load that way.  That’s fine if the web page triggers a web service or some internal function that you are targeting, where one simple button push on the web page will then trigger what you are attempting to profile.  Any more than that, however (for example a case where you need to simulate a sequence of events or otherwise and don’t want to have to do it manually every time) and you may want to consider launching the load testing tool for example against the site while the application is under the profiler.

Tom Arnold on a recent MSDN Forum post explained how do this this for unit tests, another angle to approach this is to set up a performance session against the ASP.NET application (open the ASP.NET application in Visual Studio and then use the Tools->Performance Tools->Performance Wizard to create the peformance session.  Press that nifty green arrow in the performance explorer, this will launch the performance session such that an IE browser window pops up with the URL indicated as the default URL for the project (sometimes this doesn’t exactly match up with a valid web page for that web application, and you can get a misleading 404, but I digress).  The key to understanding this whole process is the instance of the IE browser is what controls the start/stop of the performance session.  But you don’t have to use IE to generate the load, once the profiler is attached to your ASP.NET application you can use any tool capable of sending HTTP requests to exercise your application at that point.  So minimize it – just make sure you leave it open in the background – and then switch to exercising the ASP.NET application that is now being profiled using the integrated load testing tools or other test tools you may have for testing the website.  This allows you to exactly replicate a sequence of events so that you don’t have to do them manually each time, and also gives you some more consistency when you are comparing performance numbers between runs.   When your tests are finished against the website, close the IE browser window that was initially opened, and the IDE will clue in to this and then go through its motions of shutting down the performance session and displaying the performance report data for you.

It seems a bit clunky for me that we have this start/stop being tied to the browser process, but it’s hard for me to know for sure what people think about this, if it’s something they can live with or what would be better.  I know our dev team did the best they could before Beta 2 on this but my gut feeling is that there might be better ways of integrating all of this, so if you have suggestions send them my way.

Comments (2)

  1. Visual Studio Team System

    Beta 2 is out and thousands of you have downloaded and installed it with varying…

  2. I’ve pulled together all of the technical articles and walkthroughs from the various team member blogs…