- Introduction
- Unleash Your Web Server's True Power!
- Web Tuning Strategies
- Strategy: Optimize NT's Network Subsystem for Web-Based Workloads
- Strategy: Tune the Web Server Software Engine to Utilize All Available Server Resources
- Strategy: Tune Your Web Application to Utilize Available CPU Resources
- Strategy: Design the Disk Subsystem Layout for the Low Latency
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Strategy: Optimize NT's Network Subsystem for Web-Based Workloads
Tactic 1: Ensure That There Are No Server-Related Network Bottlenecks
Web server activity places a particularly heavy strain on a server's network subsystem, NT's TCP stack, and the network interface card (NIC). First and foremost, ensure that the network path to your Web server is not a bottleneck. You may not have control of each customer's network bandwidth, but at a minimum, you can ensure that your piece of the puzzle is running free of bottlenecks. Under NT, the two most common Performance Monitor (Perfmon) counters to use to detect a network bottleneck are listed here:
-
Network Segment object: %Network Utilization—This counter determines the total amount of bandwidth that is being used by your Web server. NT servers are commonly connected to the network via an Ethernet switch. For this environment, if the %utilization is greater then 70 percent, your network connection is limiting your performance. If your server is connected to the network via a shared Ethernet connection (nonswitched), consider the network connection saturated around 40–50 percent utilization.
-
Connections Established—This counter measures the number of simultaneous TCP connections last detected in the Established or Closed-wait State. Over time, if this counter is not dynamically changing but hits a plateau, it is probably time to increase your bandwidth and ensure that other NT resources are not throttling the performance of your Web server. Your Web server solution will run only as fast as your slowest utilized resource.
You can remove NT network bottlenecks by increasing the bandwidth of the technology used (10BASE-T, 100BASE-T, Gigabit Ethernet) or by using multiple NICs (such as LAN connections) in a trunking fashion. Trunking LAN connections is not provided natively by NT Server, so for this option, consider utilizing a third-party software package such as Adaptec's Duratec or NSI's Balance Suite.
If you are in the planning stages of your Web site, remember to plan for the worst case, not the average. If you have to support a large promotion, the hit rate on your site can sky-rocket, and so will the bandwidth requirements. There is no faster way to lose customers than to promote a special and then turn people away at the door by making them wait more then a few seconds for a response. Typically, plan for at least a 40 percent increase in all server resources during very active periods.
Tactic 2: Tuning TCP-Related Registry Values to Improve Network Response Times
Now that the superhighway leading to your Web server is not a bottleneck, consider optimizing NT's TCP stack. You want your NT Web server to respond to as many connection as your resources will allow, so don't let an ill-tuned TCP stack stand in your way and slow you down—tune it! The transmission control blocks store data for each TCP connection. A control block is attached to the TCB hash table for each active connection. If there are not enough control blocks available when a Web request (http) arrives at your server via TCP/IP, there is added delay while it waits for additional control blocks to be created. By increasing the TCB timewait table size, latency overhead is reduced by allowing more Web connections to be serviced in a faster fashion. To adjust this value, add the following registry value:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\MaxFreeTcbs=0xFA0.
This example increases the TCB timewait table to 4,000 entries from the default of 2,000. Now that overhead time introduced by TCP is lowered for the Web server, you must adjust the corresponding hash table, which is where the TCBs are stored. Accomplish this by adding the registry value HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\MaxHashTableSize=0x400. This increases the TCB hash table size from 512 to 1,024, allowing more room for connection information. TCB information is stored in the nonpaged memory pool. If the Web server is experiencing memory bottlenecks and more memory cannot be allotted to the server, lower the previous values. Refer down to the memory tactics (Tactic 4) area to determine NT memory usage.
Tactic 3: Tuning NIC Card Usage for Improved Web Server Response Time
Another way that you can you can improve your Web server response time is by optimizing the NIC and CPU relationship for Web server workloads. Each Web request received over the network generates an interrupt to the processor requesting service. If the processor does not find the request urgent enough (a high enough interrupt level), it will defer the request. This deferred interrupt request becomes a Deferred Procedure Call (DPC). As more and more requests come into the Web server, the number of interrupts and DPCs increase.
When an interrupt is sent to a particular CPU and it gets deferred, additional server overhead is occurred if this DPC is shipped off to another CPU in the server. This is NTs default behavior and can be costly from a performance perspective. To stop this from happening, set the registry value HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NDIS\Parameters\ProcessorAffinityMask to 0. This forces the CPU that handled the interrupt to also handle any associated DPCs. This also ensures that the network interface card or cards are not to associated with a specific CPU. This improves the CPUs servicing of interrupts and DPCs generated by the network interface card(s).