Quick ways to boost performance and scalability of ASP.NET, WCF and Desktop Clients

There are some simple configuration changes that you can make on machine.config and IIS to give your web applications significant performance boost. These are simple harmless changes but makes a lot of difference in terms of scalability. By tweaking system.net changes, you can increase the number of parallel calls that can be made from the services hosted on your servers as well as on desktop computers and thus increase scalability. By changing WCF throttling config you can increase number of simultaneous calls WCF can accept and thus make most use of your hardware power. By changing ASP.NET process model, you can increase number of concurrent requests that can be served by your website. And finally by turning on IIS caching and dynamic compression, you can dramatically increase the page download speed on browsers and and overall responsiveness of your applications.

Read the CodeProject article for more details.

http://www.codeproject.com/KB/webservices/quickwins.aspx

image

Please vote for me if you find the article useful.

5 thoughts on “Quick ways to boost performance and scalability of ASP.NET, WCF and Desktop Clients”

  1. Hi Omar,

    Thanks for your Tips. We still couldn’t get it work after changing ConnectionManagement settings. Set to 500 on each service url.

    We’re using Asp.net 4.0 with Windows 2003 with 24 cpu. We’re making 3 web services calls (from server side asp.net code) to iPlanet Web server using WCF basichttp binding..

    With 300 concurrent user hitting asp.net load test, we’re not seeing the same number in the iPlanet server?
    Also how to monitor the asp.net server side ws calls?

    Thanks,

    Gopi

  2. Let’s confirm you have set all three to very high value:

    system.servicebehaviors -> throttling values
    system.net -> connectionManagement -> maxConnection
    processModel -> maxWorkerThreads=”500″
    maxIoThreads=”500″
    minWorkerThreads=”250″
    minIoThreads=”250″

    On my article, I have put a screen shot of what counters you need to monitor. Can you monitor those counters and see where’s the bottleneck?

  3. Thanks for the quick Reply.

    1. System.servicebehavors –> Why we need this? since we’re not using WCF on both the ends. The other end is a iPlanet web server.
    From Asp.net code we just use WCF client channel to connect to an http web service!
    I was of the opinion throttling values are applicaple only for clients connecting to a WCF Server Host.

    2. For each of the 3 Web service url used, we are using 500 as the limit.

    3. ProcesModel is set to “AutoConfig” since we’re using .net 4.0 and MS tech guys recommended this setting rather tuning each, as .NEt 4 improved these property management, esp if we use multi-core.

    Regarding the perf counters: We’re monitoring all of the Asp.net 4.0 Counters, the Requests /sec (from the load runner) comes as ~ 100 /sec on peak 350 user loads with 70% cpu (all 24 cpu combined!)

    The other two objects are not monitored (the sevicemodel & web service) as explained above. There are activities in web service counters to the 20’s and 30’s (Get and Post) which i guess is measuring the traffic from load runner (browser clients)

    Thanks,

    Gopi

  4. Hello Omar,

    I am a big fan of your blogs and articles.

    I have a website which makes AJAX calls to WCF service using JavaScript. (I am not using jQuery but using ASP.Net AJAX service reference).

    From my page I am making 4/5 AJAX calls, but the calls are getting executed / called synchronously, they are not parallel. This is causing the problems like slow loading. What can be the reason behind? I checked if the first AJAX call is really blocking the thread ( By making the thread sleep for few seconds) and it’s really blocking the requests.

  5. Very nice article!
    apart from all these configurations when load (frequent database calls load) increases the performance of asp.net app decreases so at that point app needs to cache data in order to enhance performance but it couldn’t be scalable because Asp.Net Cache is in-process and standalone, which means scalability will always be an issue. So to solve these issues Distributed cache (like NCache) is used it provides scalability, availability and performance that a high end application needs to do well.

Leave a Reply