Starting with Windows Server 2008, one of the most significant changes to the TCP stack is TCP receive window auto-tuning. Previously, the network stack used a fixed-size receive-side window that limited the overall potential throughput for connections. You can calculate the total throughput of a single connection when you use this fixed size default as:
Total achievable throughput in bytes = TCP window * (1 / connection latency)
For example, the total achievable throughput is only 51 Mbps on a 1-GB connection with 10-ms latency (a reasonable value for a large corporate network infrastructure). With auto-tuning, however, the receive-side window is adjustable and can grow to meet the demands of the sender. It is entirely possible for a connection to achieve a full line rate of a 1-GB connection. Network usage scenarios that might have been limited in the past by the total achievable throughput of TCP connections now can fully use the network.
Remote file copy is a common network usage scenario that is likely to increase demand on the infrastructure because of this change. Many improvements have been made to the underlying operating system support for remote file copy that now let large file copies perform at disk I/O speeds. If many concurrent remote large file copies are typical within your network environment, your network infrastructure might be taxed by the significant increase in network usage by each file copy operation.
Windows Filtering Platform
The Windows Filtering Platform (WFP) that was introduced in Windows Vista and Windows Server 2008 provides APIs to third-party independent software vendors (ISVs) to create packet processing filters. Examples include firewall and antivirus software. Note that a poorly written WFP filter significantly decreases a server’s networking performance. For more information about WFP, see "Resources" later in this guide.
The following registry keywords in Windows Server 2003 are no longer supported and are ignored in Windows Server 2008 and Windows Server 2008 R2:
HKLM\System\CurrentControlSet\Services\Tcpip\Parameters
HKLM\system\CurrentControlSet\Services\Tcpip\Parameters
HKLM\system\CurrentControlSet\Services\Tcpip\Parameters
Network-Related Performance Counters
This section lists the counters that are relevant to managing network performance. Most of the counters are straightforward. We provide guidelines for the counters that typically require explanation.
IPv4
Datagrams received per second.
Datagrams sent per second.
IPv6
Datagrams received per second.
Datagrams sent per second.
Network Interface > [adapter name]
Bytes received per second.
Bytes sent per second.
Packets received per second.
Packets sent per second.
Output queue length.
This counter is the length of the output packet queue (in packets). If this is longer than 2, delays occur. You should find the bottleneck and eliminate it if you can. Because NDIS queues the requests, this length should always be 0.
This counter is the number of incoming packets that contain errors that prevent them from being deliverable to a higher-layer protocol. A zero value does not guarantee that there are no receive errors. The value is polled from the network driver, and it can be inaccurate.
Processor Information
Percent of processor time.
Interrupts per second.
DPCs queued per second.
This counter is an average rate at which DPCs were added to the processor's DPC queue. Each processor has its own DPC queue. This counter measures the rate at which DPCs are added to the queue, not the number of DPCs in the queue. It displays the difference between the values that were observed in the last two samples, divided by the duration of the sample interval.
TCPv4
Connection failures.
Segments sent per second.
Segments received per second.
Segments retransmitted per second.
TCPv6
Connection failures.
Segments sent per second.
Segments received per second.
Segments retransmitted per second.
Performance Tuning for the Storage Subsystem
Decisions about how to design or configure storage software and hardware usually consider performance. Performance is degraded or improved as a result of trade-offs with other factors such as cost, reliability, availability, power, or ease of use. Trade-offs are made all along the path between application and disk media. File cache management, file system architecture, and volume management translate application calls into individual storage access requests. These requests traverse the storage driver stack and generate streams of commands that are presented to the disk storage subsystem. The sequence and quantity of calls, and the subsequent translation, can improve or degrade performance.
Figure 3 shows the storage architecture, which covers many components in the driver stack.
Figure 3. Storage Driver Stack
The layered driver model in Windows sacrifices some performance for maintainability and ease of use (in terms of incorporating drivers of varying types into the stack). The following sections discuss tuning guidelines for storage workloads.
|
