locked
Performance Issues After Installing Visual Studio 2008 RRS feed

  • Question

  • I work on an ASP.NET web application with code behind written in C# which requires users to login.  Upon login the app sends an asynchronous SOAP request to a Web Service that authenticates the user in Active Directory.

    The previous version of our application was built using Visual Studio 2005 and the version currently in development is being built using Visual Studio 2008.  This is the only change that has been made with respect to user login.  Our domain controller and Active Directory have not changed either.

    At the end of each development cycle we execute a suite of performance tests.  One test in particular tracks the execution time for 50 users logging in simultaneously.  In our previous version (built using Visual Studio 2005) it took each user 6 seconds to login with 50 concurrent users.  In the version in development (built using Visual Studio 2008) it takes each user upwards of 30 seconds to login with 50 concurrent users.

    So my question is: Does any one know how building in Visual Studio 2008 could impact performance in either SOAP communication or access to Active Directory?

    Ray Saltrelli
    • Edited by Ray Saltrelli Wednesday, October 8, 2008 1:30 PM
    • Moved by Peter Ritchie Tuesday, October 14, 2008 2:39 PM ASP.NET topic (Moved from Visual C# General to Off-Topic Posts (Do Not Post Here))
    Wednesday, October 8, 2008 1:27 PM

Answers

  • FYI,  the problem turned out to be that the newer version of the application was sharing an app pool with others sites.  Visual Studio 2008 had nothing to do with the performance degradation.
    Ray Saltrelli | Software Engineer | Mindex Technologies Inc. | Rochester, NY
    • Marked as answer by Ray Saltrelli Monday, October 13, 2008 6:41 PM
    • Marked as answer by Ray Saltrelli Monday, October 13, 2008 6:41 PM
    Monday, October 13, 2008 6:41 PM

All replies

  •  If this is on Windows XP with SP2 (you didn't happen to install that at the same time did you?), it has a 10 TCP connection per second limit.  If Visual Studio 2008 is using more TCP connections for whatever reason, this would affect your performance tests.  There's nothing more than hacks to overcome this limit; so, I would suggest doing performance tests with multiple computers or a server-class OS like Windows Server 2008.
    http://www.peterRitchie.com/blog
    Wednesday, October 8, 2008 1:41 PM
  • Yes, we are using Windows XP SP2 on both the Web and DB servers.  

    Is there any way to verify that this is the problem?

    Ray Saltrelli | Software Engineer | Mindex Technologies, Inc. | Rochester, NY
    Wednesday, October 8, 2008 2:04 PM
  • The way to verify would be to run the performance test on an OS other than Windows XP SP2.  You should be doing this anyway, trying to run more than 50 concurrent TCP connections in Windows XP SP2 should theoretically never be faster than 50 seconds without ever transferring application data.

    I'm not clear what happens when 10 connections per second is reached, if it just stops connections for one second or whether it stops connections for more than one second; so, it could be more than 50 seconds.
    http://www.peterRitchie.com/blog
    Wednesday, October 8, 2008 2:09 PM
  • I appeciate your help but I remain a little skeptical.  Primarily because the previous version of our app ran so much fast (also on Windows XP SP2).

    How could a different compiler introduce more TCP connections if we are using the same .NET framework in both versions (.NET 2.0)?

    Ray Saltrelli | Software Engineer | Mindex Technologies Inc. | Rochester, NY
    Wednesday, October 8, 2008 2:15 PM
  • Are you using Visual Studio 2008 SP1?  If so, that includes a service pack for the .NET framework.  So, there's all sorts of code that could be different, both in your application and in Visual Studio.  I'm assuming that you're using a Visual Studio performance test unit test for your performance testing.  It could be that the unit test code makes more TCP requests than it used to, affecting the number of concurrent TCP connections being opened during the test.  There's also the possiblity that the Visual Studio Start Page RSS reader is making more requests per second.  Visual Studio 2008 SP1 includes support for debugging the .NET framework via online source servers; if that's turned on there will be many more TCP connections to the source server at Microsoft.  ...just to name a few.  These things would obviously affect your network bandwidth in general; but would only affect the number of connections per second you can attain only on Windows XP SP2.

    There's nothing documented on Visual Studio 2008 causing SOAP connections to be slower, that I am aware of.

    You could try using something like Fiddler to see how many TCP connections are being opened durning the tests.  If you ran the tests in VS 2005 and in VS 2008 with Fiddler you could see if there is an increase in connections.
    http://www.peterRitchie.com/blog
    Wednesday, October 8, 2008 2:37 PM
  • True, Visual Studio 2008 SP1 installed .NET 3.5 but we are not using is.  Our target framework is still .NET 2.0.

    For our performance tests we are using a third-party application called LoadRunner.  Visual Studio is installed on our Web server but it is not running during the tests.

    I will try Fiddler and see what it shows.

    Ray Saltrelli | Software Engineer | Mindex Technologies Inc. | Rochester, NY
    Wednesday, October 8, 2008 2:48 PM
  • Ray Saltrelli said:

    True, Visual Studio 2008 SP1 installed .NET 3.5 but we are not using is.  Our target framework is still .NET 2.0.




    .NET 3.5 includes a service pack for .NET 2.0 (SP2).  That's why the .NET 2.0 version gets bumped up to 2.0.50727.3053 (from 2.0.50727.42 or 2.0.50727.1433).  So, even if you target 2.0, your application is still, likely, using a bunch of new code.

    If you retest with VS2005 on a computer with VS2008 installed, you will be able to tell if the .NET 2.0 SP2 update was likely the reason for the performance change.  If there's no change to the performance running under VS2005 then you know the culprit is VS20080.
    http://www.peterRitchie.com/blog
    • Edited by Peter Ritchie Wednesday, October 8, 2008 3:10 PM spelling
    Wednesday, October 8, 2008 3:10 PM
  • My apologies.  I have us barking up the wrong tree.

    Our web server where we do our testing is running Windows Server 2003 SP2 and .NET 2.0 SP1.  So as far as I can tell, the only difference between the fast version and the slow version is the compiler that was used.  Does this sound accurate?

    I found another thread indicating that the VS2008 project converter can bobble the optimization settings.  I inspected my VS2008 project files and the "Optimize code" check box is checked for Release mode as it should be.  Are there other settings I should look at?

    Ray Saltrelli | Software Engineer | Mindex Technologies Inc. | Rochester, NY
    Wednesday, October 8, 2008 3:36 PM
  • I also found this post indicating that the .NET JIT compiler optimizations can actually make code run slower in some cases.  Does this sound relevant?
    Ray Saltrelli | Software Engineer | Mindex Technologies Inc. | Rochester, NY
    Wednesday, October 8, 2008 5:38 PM
  • FYI,  the problem turned out to be that the newer version of the application was sharing an app pool with others sites.  Visual Studio 2008 had nothing to do with the performance degradation.
    Ray Saltrelli | Software Engineer | Mindex Technologies Inc. | Rochester, NY
    • Marked as answer by Ray Saltrelli Monday, October 13, 2008 6:41 PM
    • Marked as answer by Ray Saltrelli Monday, October 13, 2008 6:41 PM
    Monday, October 13, 2008 6:41 PM