Export (0) Print
Expand All

Monitoring TCP Connections

Updated: August 22, 2005

Applies To: Windows Server 2003, Windows Server 2003 with SP1

If the bandwidth of your server is insufficient to handle its workload, clients usually become aware of this before the server does. Client requests to the server might be rejected or time out or the response might be delayed. On the server side, the indicators are less clear because the server continues to establish connections, receive requests, and transmit data.

Bandwidth shortages are not uncommon. You can detect one on your server (perhaps even before clients do) by monitoring the success and failure of connections established and rejected by TCP. With ample bandwidth, the server can establish and serve connections before they time out. If bandwidth is insufficient, the connections fail.

Table 6.10 lists the counters that monitor the success and failure of connections to TCP. Windows Server 2003 provides two TCP objects, TCPv4 and TCPv6; choose the counter that monitors the version of TCP that your server is using.

Table 6.10 Counters for Monitoring the Success or Failure of TCP Connections

Object\Counter Value

TCPv4\Connections Established

TCPv6\Connections Established

The number of simultaneous connections supported by TCP. This counter displays the number of connections last observed to be in the ESTABLISHED or CLOSE-WAIT state. This counter displays the last observed value (indicating the current state); its value is not an average.

TCPv4\Connection Failures

TCPv6\Connection Failures

The number of connections that have failed since the service was started (regardless of when you started System Monitor). TCP counts a connection as having failed when it goes directly from sending (SYN-SENT) or receiving (SYN-RCVD) to CLOSED, or from receiving (SYN-RCVD) to listening (LISTEN).

TCPv4\Connections Reset

TCPv6\Connections Reset

The number of connections reset since the service was started (regardless of when you started System Monitor).

TCP counts a connection as having been reset when it goes directly from ESTABLISHED or CLOSE-WAIT to CLOSED.

The counters on the TCPv4 and TCPv6 objects are the best indicators of the success of connection requests. The counters on the Web Service and FTP Service performance objects monitor connections maintained by each IIS 6.0 service, but display only successful connection requests, not failed attempts. Like all counters at the application layer, they do not have information about connections until the connections are established.

For a discussion of performance counters that display the number of simultaneous connections maintained by IIS 6.0, see Preventing Processor Bottlenecks.

Analyzing the Data

If your server does not support current or increasing demand, look for the following patterns when you analyze the data from the TCP\Connections counters:

  • Look for a plateau in the Connections Established counter value. If the counter value of TCP\Connections Established often reaches, but rarely exceeds, a maximum value (that is, the line in the graph rises and then reaches a plateau), the peak value is likely to indicate the maximum number of connections that can be established with the current bandwidth and application workload. If you observe such a pattern, the server probably cannot support any greater demand.

  • Look for consistent increases of the Connection Failures and Connections Reset counter values. An increasing number of failures and resets, or a consistently increasing rate of failures and resets, can indicate a bandwidth shortage. The counters that monitor failures and resets show cumulative values, but you can use Performance Logs and Alerts to set alerts on the values or to log values over time. You can then use a spreadsheet to calculate the rates at which connections are rejected and reset.

    noteNote
    Be cautious when interpreting the number of reset connections shown by the TCP\Connections Reset counter. Resets do not always indicate dropped or failed connections. To minimize connection overhead, many browsers routinely close connections by sending a TCP reset (RST) packet rather than by using a normal close operation. The TCP\Connections Reset counter does not distinguish between connections that are reset because they are dropped and those that are reset in order to be closed abruptly.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft