Symantec Management Platform (Notification Server)

 View Only

Tuning Microsoft .NET to Speed Up Notification Server 

May 14, 2008 02:41 PM

The Altiris Notification Server 6.x platform was coded using Microsoft's .NET platform and heavily relies upon ASP.NET for much of the functionality of the product. By tuning the default configuration of ASP.NET, a significant performance improvement can be gained on Altiris Notification Servers.

Note that the following recommendations and settings are referenced in Microsoft's online publications. More information can be found by visiting the following Microsoft MSDN web pages:

"Improving .NET Application Performance and Scalability," Chapter 6, http://msdn.microsoft.com/en-us/library/ms998530.aspx

"Thread Pool Attributes" in Chapter 17, "Tuning .NET Application Performance." http://msdn.microsoft.com/en-us/library/ms998583.aspx

To tune the ASP.NET software installed on the Notification Server, open the "C:\Windows\Microsoft.NET\Framework\v1.1.4322\Config\Machine.config file" in Microsoft Notepad or another text editor and apply the following changes:

  1. Set maxconnection to 12 * # of CPUs. This setting controls the maximum number of outgoing HTTP connections that you can initiate from a client. In this case, ASP.NET is the client.
  2. Set maxIoThreads to 100. This setting controls the maximum number of I/O threads in the .NET thread pool. This number is automatically multiplied by the number of available CPUs.
  3. Set maxWorkerThreads to 100. This setting controls the maximum number of worker threads in the thread pool. This number is then automatically multiplied by the number of available CPUs.
  4. Set minFreeThreads to 88 * # of CPUs. This setting is used by the worker process to queue all the incoming requests if the number of available threads in the thread pool falls below the value for this setting. This setting effectively limits the number of requests that can run concurrently to maxWorkerThreads - minFreeThreads. This limits the number of concurrent requests to 12 (assuming maxWorkerThreads is 100).
  5. Set minLocalRequestFreeThreads to 76 * # of CPUs. This setting is used by the worker process to queue requests from localhost (where a Web application sends requests to a local Web service) if the number of available threads in the thread pool falls below this number. This setting is similar to minFreeThreads but it only applies to localhost requests from the local computer.

The following occurs if the formula has worked:

  1. CPU utilization increases.
  2. Throughput increases according to the ASP.NET Applications\Requests/Sec performance counter.
  3. Requests in the application queue decrease according to the ASP.NET Applications/Requests In Application Queue performance counter.

Microsoft points out that while these settings provide a good baseline your company may need to revisit these values if the server experiences performance problems.

Table 6.1: Recommended Threading Settings for Reducing Contention

Configuration Setting Default Value (.NET Framework 1.1) Recommended Value
maxconnection 2 12 * #CPUs
maxIoThreads 20 100
maxWorkerThreads 20 100
minFreeThreads 8 88 * #CPUs
minLocalRequestFreeThreads 4 76 * #CPUs

Statistics
0 Favorited
0 Views
0 Files
0 Shares
0 Downloads

Tags and Keywords

Comments

Sep 25, 2008 04:38 PM

I tried this and it brought my machine to a crawl. If I had more RAM and more cores it would probably have helped, so if you don't have a beefy machine, this may not be for you.

May 15, 2008 09:56 AM

Scott's warning is related to a common scenario where customers have improperly configured SQL environments. Yes, making these edits will expose a poor performing SQL server and will lead to deadlocks. However customers that have properly scoped SQL servers will not have these problems.
That being said, servers running as Reporting Servers, Asset Management Servers and Helpdesk servers are better candidates for these tweaks.
As with any tips you find on Juice or anywhere else, these setting should be tested and tweaked in your lab environment. Your milage may vary.

May 14, 2008 10:40 PM

This post is similar to another one made about a year ago?
A client facing NS, such as a CMS server) does NOT have bottlenecks when it comes to .NET threads. In almost all cases, the bottleneck is the SQL server. This is not to say that the code is perfectly optimized, but you can't improve wait times on SQL responses by increasing thread utilization.
Increasing .NET threads can actually harm performance by increasing the number of concurrent SQL operations, which in turn increases the likelihood of SQL deadlocks.
On the other hand, Helpdesk solution is far more CPU intensive. Careful .NET thread tuning (on a dedicated helpdesk server) has shown the ability to handle more concurrent Helpdesk workers, with improved average response times. This kind of tuning requires baselining and some sort of HTTP load simulation tool. It is not something that should be casually done on a production server.

Related Entries and Links

No Related Resource entered.