NS Console Performance - reducing Console latency


Article ID: 180995


Updated On:


Management Platform (Formerly known as Notification Server)




I am working in a fast LAN environment, and the Notification Server is not very heavily loaded, but the Altiris Console is still a little slow at responding to commands. Is there anything I can do to make the console respond faster?


Before applying the change which is explained in this article, I would strongly encourage you to read and apply KB33499.

In the early days of the ARPANET, clients would send out packets for every piece of data that they generated however small. As network traffic intensified, this quickly became a problem and a guy called John Nagle came up with an algorithm which would buffer small messages on the client and send them as a single packet. This algorithm was very successful at reducing the amount of network traffic and now is built into every TCP/IP stack. The downside to this is that in intensive client/server applications, the algorithm will introduce a short delay while it waits to see if it can fill a packet from the buffer to send to the server.

Another feature of the TCP/IP stack which is aimed at increasing the efficiency of client/server communications, is the Expect100Continue packet. When a client wishes to communicate with a server it will send this packet and wait for the server to deliver a 100-Continue packet in response. When the client receives this packet, it then proceeds sending its request. In effect, the client is "pinging" the server to see if it can accept the data that it wishes to transmit before sending it.

The use of both Nagle's Algorithm and Expect100Continue can be disabled and in a LAN environment where the cost/packet is low, this can lead to significantly reduced latency.

To disable these mechanisms on your Altiris Notification Server, follow these steps:
  • Browse to the folder - C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\CONFIG
  • Open the file machine.config with notepad
  • Locate the node  <system.net> <settings>
  • Add this element to that node :

<servicePointManager expect100Continue="false" useNagleAlgorithm="false"/>

  • The section should now read:

     <servicePointManager expect100Continue="false" useNagleAlgorithm="false"/>
   <servicePointManager checkCertificateName="true" checkCertificateRevocationList="false"/>
            httpWebRequest Attributes:
                maximumResponseHeadersLength="[KBytes]" - KBytes size of maximum response headers length to accept
   <httpWebRequest maximumResponseHeadersLength="64"/>
                The following entry enables IPv6 support in the System.Net classes.
                IPv6 support is predicated on availability of an IPv6 WinSock provider,
                use of Windows XP and the switch below being set to "true".
   <!-- <ipv6 enabled="false"/> -->

  • Save the file.
  • Restart the IIS Service on the server or reboot the machine if you prefer.

You may or may not benefit from these changes as the reduction in latency will come at the cost of increased network traffic, however it is worth experimenting with especially if you have fast network connections.