The past few days I have been working on Load and stress testing some workflow implementations that work with the WCF input activities I created (I published them at Codeplex for you to use as well http://www.codeplex.com/WCFWorkflow )
This project has some very interesting non-functional requirements where we need to process more than 300.000 workflows a day. If you take into account that each workflow has between the 30 and 60 activities, you might imagine that we need to do some thorough performance and load testing.
Of course I advised the team to go ahead and use the Team System Load test tools. The great thing is that you can leverage some of your unit tests to exercise the host application, so that saves a lot of time in creating the appropriate test mixes.
We found after running the first tests that we might have hit a performance bottleneck, so I wanted to dive a little deeper and see where the problem is caused. We found that we generated way too much CPU load and therefore I wanted to do some performance profiling using the profiling tools of TFS.
This was a little bit harder than expected. This had to do with the fact that when using the performance explorer and selecting the web application project that has the .svc files it will only fire up a web browser, and the IDE won’t let you fire the unit tests any more, since it will throw an exception stating: Code coverage collection error: VS performance and coverage logger engine is already running on machine.
The only way to exercise your application using the unit tests is to do it using the command line. using MSTest from the command line is not so hard, but I got faced with another problem using this solution. I used the [AspNetDevelopmentServer("WorkflowHost", @"..\..\TestWCFActivities", "/")] attribute to enable the the website host applciation to start before you run the unit test. The problem I faced is that when the performance explorer is started it will host the development webserver already and the unit test will start its own as well. This would then result in not hitting your website monitored by the performance proflier.
Since there is no option to force the AspNetDevelopmentServer to use a fixed port, I needed to manualy change the configuration files before I could run the unit test. I finaly got the unit test to hit the host webserver, but I must say that in dodays SOA driven application development I expected this to be a bit smoother. To sum it up for you to run a performance profile of a webservice or WCF service you need the following steps:
· Create a performance session using the performance wizard selecting your web application hosting the services
· Start the performance profiler
· Start a command line window to start MSTest manually
· Change your unit test config file to point to the correct endpoint started by the performance session
· Run the unit test from the command line
· Stop the performance session and analyse the results.
Creat thing is that using the Load test and profiling tools I found a memory leak and a race condition in my code. I now fixed at codeplex as well J