Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
  • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
  • H04L41/5003—Managing SLA; Interaction between SLA and QoS
  • H04L41/5009—Determining service level performance parameters or violations of service level contracts, e.g. violations of agreed response time or mean time between failures [MTBF]
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L43/00—Arrangements for monitoring or testing data switching networks
  • H04L43/06—Generation of reports
  • H04L43/062—Generation of reports related to network traffic
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L43/00—Arrangements for monitoring or testing data switching networks
  • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
  • H04L43/0852—Delays

Definitions

• the present invention relates to systems and methods for determining server and network response times and other performance parameters within a client-server network by monitoring communications between a client and a server.
• Networks including local area networks (LANs) and wide area networks (WANs), are becoming increasingly prevalent as the number of computational devices in organizations grows. Networks enable information to be shared between computational devices, and as such are important for the ease and convenience of storing and accessing data throughout an organization.
• Networks are implemented with a connection between at least two computational devices or other network hardware devices. This connection can exist, for example, over a cable or a wireless link, and can be implemented using optical, electrical, infra-red or radio wave based signals (or a combination thereof). Data is passed through this connection according to various protocols at different layers of the network.
• protocols include but are not limited to, transmission control protocol (TCP), Internet protocol (IP), Internet packet exchange (IPX), systems network architecture (SNA), datagram delivery protocol (DDP) and so forth.
• TCP transmission control protocol
• IP Internet protocol
• IPX Internet packet exchange
• SNA systems network architecture
• DDP datagram delivery protocol
• TCP transmission control protocol
• IPX Internet packet exchange
• SNA systems network architecture
• DDP datagram delivery protocol
• TCP transmission control protocol
• IP Internet protocol
• IPX Internet packet exchange
• SNA systems network architecture
• DDP datagram delivery protocol
• FDDI fiber distributed data interface
• a message stream between a client and a server is monitored from a location on a network in order to determine specific parameters of the performance of the network, the server, or both.
• the message stream is a TCP or other non-application-specific message stream, and is monitored passively by a computational device that is local to the client; by a device that is local to the server, or both.
• One or more specific performance parameters are measured by determining the amount of time between specific messages that correspond to specific stages or events of a client-server session. Because these messages and events are not application-dependent, the performance parameters may be determined without regard to the type of application used within the session, and without prior knowledge of the type of application data requested by the client.
• the measured performance parameters include connect time, network latency, server response time, network bandwidth, and server bandwidth.
• One aspect of the invention is thus a method of monitoring performance of a client-server network from a location on the network.
• the method comprises (a) monitoring a message stream on the network between a client and a server during a client-server session, (b) detecting a first message of the message stream and a second message of the message stream, wherein the first and second messages are selected to correspond to non-application- dependent events of the session, and (c) measuring an elapsed time between detection of the first message and detection of the second message to determine a parameter of either network performance or server performance. Performance is thereby measured without regard to a type of application used within the client-server session.
• the system comprises a computational device connected to the network and configured to monitor a message stream between a client and a server at an application-independent protocol level during a client- server session.
• the system further comprises a program module which uses the message stream as monitored by the computational device to measure performance of the network and/or the server.
• the program module measures an elapsed time between receipt by the computational device of a first message of the message stream, and receipt by the computational device of a second message of the message stream, to determine a parameter of either network performance or server performance.
• the first and second messages correspond to selected non-application-dependent events within the client-server session.
• the system comprises a computer connected to the network and configured to passively monitor a Transmission Control Protocol (TCP) message stream between a client and a server during a session between the client and the server.
• TCP Transmission Control Protocol
• the system further comprises a program module which uses the message stream as monitored by the computer to measure performance of the network and/or the server.
• the program module measures an elapsed time between receipt by the computer of a first TCP message of the message stream, and receipt by the computer of a second TCP message of the message stream, to determine a parameter of either network performance or server performance, wherein the first and second TCP messages correspond to selected non- application-dependent events within the session.
• FIG. 1 is a schematic block diagram of an illustrative system according to the present invention
• FIG. 2 is a schematic block diagram of an illustrative session for measurement of performance parameters according to the present invention.
• FIG 3 is a flow diagram of a process for measuring performance parameters of the type illustrated in FIG 2.
• the present invention provides a system and method for automatic measurement of the performance of a client-server network, including the separate measurement of the performance of the server and of the network.
• the performance measurements are generated by measuring elapsed times between specific messages between the client and server as monitored from a location at or near the server, and/or from a location at or near the client.
• the measurements could be taken from substantially any location on the network from which the client- server message stream may be monitored, although the "meanings" of the measurements are dependent upon the monitoring location.
• the method or process of the present invention can be described as a series of steps or tasks implemented by a data processor, such that the process can be implemented as hardware, software or firmware, or a combination thereof.
• the process is embodied within a software application (program) which runs on one or more general-purpose computers.
• the software application may be written in any suitable programming language such as C, C + + and Java.
• messages between the client and server are analyzed at the TCP layer, or other application-independent protocol layer, in order to determine the response times and other performance parameters of the server and/or the network.
• the various response times and other parameters are measured without reliance on application-specific information within the message stream.
• An important benefit of this method is that no advance knowledge is required of the type of application data requested by the client.
• the data analysis is optionally and preferably performed by listening for TCP frames that indicate the state of the session between the client and the server.
• the TCP messages are monitored with a hardware connection device connected to the network in a promiscuous mode in which all local network traffic passes through the connection device.
• the analysis is performed on data received through a single port.
• data received through each port is preferably analyzed separately for the response time of the server and/or of the network. Since such complex requests are actually a combination of multiple simple requests, the performance of the server and/or of the network can be determined by decomposition of the received data.
• separate measurements may be performed at or near the server, and at or near the client on the network.
• FIG. 1 is a schematic block diagram of a system 10 for determining the performance of a network 12.
• the system includes a server 14 and a client 16, which are typically located remotely from one another.
• the client and the server are connected to network 12, which is preferably a network that supports TCP.
• network 12 is preferably a network that supports TCP.
• the client device 16 may, for example, be a handheld computer, a WAP (Wireless Access Protocol) or other wireless phone, a data appliance, or any other type of data processing device which makes requests on a network as a client.
• the server 14 can be any type of data processing device, or combination of data processing devices, which respond to such requests as a server.
• the system also includes a sampler 18 connected to the network 12.
• Sampler 18 is preferably operated by a computational device or computer 20, also termed a "measurement computational device" for distinguishing computational device 20 from server 14 and the client 16.
• the measurement computational device 20 includes a network card 22 or other network connector hardware device.
• the network card 22 is able to listen to local traffic passing through or along the portion of the network 12 to which the measurement computational device is connected.
• connection of the measurement computational device 20 to the network 22 is preferable a hardwire connection, but could alternatively be a wireless connection (e.g., in wireless LAN environments).
• the sampler could alternatively run on the client device 16 or the server device 14 (or both).
• the computational device 20 may optionally be located at or near server 14, or at or near client 16. In each case, measurements of network performance may be made. Further, one computational device 20 may be located local to the client 16 and another computational device 20 located local to the server 14, such that a client-server session is monitored from both locations concurrently (to obtain different types of measurements, as described below). Where multiple devices are used to monitor the same session, the resulting performance measurements may be appropriately combined for purposes of analysis and reporting.
• the network card 22 receives all packets that pass through or along a portion of network 12, regardless of whether these packets are specifically addressed to network card 22 itself. Setting the network card 22 to operate in promiscuous mode is only one example of a mechanism for eavesdropping on network traffic flowing past the computational device 20 on the network 12. Adapted mechanisms could be used for eavesdropping on network traffic for networks operating through microwave or fiber optic transmissions, for example, which do not operate with network interface cards. Such adaptations could easily be performed by one of ordinary skill in the art.
• a robot 24 initiates sessions with server 14, in place of client 16, resulting in the transmission of data, for example by requesting a Web page or any type of mark-up language document or object.
• robot 24 is passive, in which case the information obtained by network card 22, which is described in greater detail below, is passed to robot 24.
• Robot 24 watches for the initiation of such a session between client 16 and server 14, and then monitors the transmission of data during the session. Because the session is monitored at the TCP layer, the ability to reliably track the session is not dependent upon the particular type of client-server application being used.
• Robot 24 is optionally and preferably implemented as an application software module, but is alternatively implemented as hardware (such as within a programmable
• robot 24 is not used to perform the measurements, which instead are performed by the server 14 and/or the client 16.
• An analyzer 26 also receives the information obtained by network card 22. Analyzer 26 calculates the amount of time required to reach each stage, thereby determining the response time of the server 14 and/or of the network 12. As described in greater detail below with regard to the TCP protocol for data transmission, analyzer 26 uses the flags or events for each stage of the session, obtained by robot 24, as well as the elapsed time at the receipt of each flag to determine various response times. Although Figure 2 illustrates the performance of robot 24 and analyzer 26 with regard to the TCP protocol for data transmission, the response times could be similarly measured for other protocols in which communication during a session occurs in clearly demarcated stages. Analyzer 26 preferably sends the analyzed data to data buffer 28.
• Data buffer 28 optionally correlates the information between analyzer 26 and robot 24, preferably performing a complete analysis of an entire session for response time, latency, and other parameters.
• the performance data may optionally be collected from a plurality of samplers 18 and stored in a database 30.
• a plurality of samplers 18 could be deployed at selected client locations (e.g., in different office buildings, cities or countries), and used to monitor performance as seen from such locations; the resulting performance data generated by such samplers may be reported to and aggregated within a central database 30 used to generate online performance reports.
• FIG. 2 shows an example client-server session, and illustrates the measurements taken by the sampler 18 (or samplers) in a preferred embodiment of the invention.
• the client and the server exchange packets with TCP commands or fields according to the TCP protocol.
• the specific performance parameters measured during the session depend upon whether a sampler is located local to the client, local to the server, or both. Specific steps or events within the session are labeled with numbers.
• Measurements shown on the client side of the drawing are taken using a computational device 20 that is local to the client, such that the sampler receives a packet at substantially the same time it is transmitted or received by the client.
• Measurements shown on the server side of the drawing are taken using a computational device 20 local to the server, such that the sampler receives a packet at substantially the same time it is transmitted or received by the server.
• the client sends a synchronize (SYN) request to the server.
• the server replies to the client with a synchronize acknowledgement (SYN/ACK) message, both acknowledging receipt of the SYN request and sending its own SYN request.
• the elapsed time between transmission of the SYN request by the client and the receipt of the SYN/ACK reply by the client is the connect time (a specific network latency measurement), when such connect time is measured at or near the client.
• the client sends an ACK message to the server. If the measurements are taken at or near the server, the connect time may be measured as the elapsed time between transmission of the SYN/ACK reply and receipt of another ACK message (labeled "server connect time" in Figure 2).
• the client sends a request to the server for particular data, such as a GET command message.
• the server replies to the client with an ACK message at event 5. Since the server sends such a reply without any processing of the request and without regard to the type of application which must handle the request, the amount of server processing time (referred to as the "kernel time") required to send the
• the amount of time that elapses between transmission of the GET message or other data request command by the client, and receipt of the ACK message from the server, as measured at or near the client, is a measure of the network latency.
• Such a measurement of network latency may optionally be further refined by subtracting the kernel time of the server, to obtain a more precise measurement of the network response time as measured at or near the client.
• network latency is also optionally measured at or near the server.
• the server sends the requested data to the client in one or more data response (“R") messages (four R messages shown).
• R data response
• the elapsed time between receipt of the GET message by the server and transmission of the first "R" message by the server is the server response time or server latency, as measured at the server.
• Preparing the requested data may require significant processing time by the server. If the request is simple, for a single type of data for example, then only one response message may be sent.
• the server's response time may also be approximated by measuring, for a location local to the client, the elapsed time between receipt of the ACK message from the server and receipt of the first R message from the server. This approximation is based on the assumption that the network latency is approximately same for both of these messages.
• a sequence of multiple consecutive R (data response) messages may be sent during event 6 to transfer the requested data.
• the server waits for, and the client sends, an ACK message (event 7).
• the server resumes transmissions of response messages as needed. This entire cycle is then repeated (as shown) until all of the data for the response has been sent from the server to the client.
• the elapsed time (as measured local to the server) between server transmission of the last R message of the sequence and receipt of the corresponding ACK message is a measure of network latency.
• another measurement that may optionally be taken is the time between consecutive R (data response) messages. This elapsed period of time is a measure of the time delay caused by the limited availability of bandwidth. If measured near the client, this time period can be used to assess network bandwidth. If measured near the server, this time period can be used to assess server bandwidth.
• the server response time is preferably measured as described above. Additionally and/or alternatively, each time data is sent to a different port, the server response time may be measured separately as for a separate response.
• An additional type of time measurement that may be performed at the server side is from receipt of the ACK message for the last R message to server transmission of a new R message to the client.
• This elapsed period of time labeled “resumed transmission response time” in Figure 2 is an additional measure of server performance. Additional measurements of network and server bandwidth, network latency, and resumed transmission response time, may be taken at later stages of the session.
• Two other performance parameters that may be determined during the client-server session are the number of server retries and the number of network retries.
• a server retry occurs when the server does not respond to a message from a client, such that the client must send the message again (not shown in Figure 2).
• a network retry occurs when the client does not send an ACK message to the server, such that the server must send the message again. If the measurements are taken at or near the server, the sampler can distinguish between network retries and server retries by determining whether a packet was dropped by the server versus the network. This is in contrast to prior systems, which generally cannot distinguish between network retries and server retries.
• the server sends a FIN message to the client (not shown).
• the difference between the time that the last response is received by the client and the time that the FIN is received by the client is another measure of network latency, although with some server processing time added.
• the client sends a FIN/ACK message to the server (not shown), and the server then returns an ACK message to the client (not shown).
• the sequence of FIN (from the server); FIN/ACK (from the client); and ACK (from the server) can be used to determine that a particular data request session is finished and a new session is about to begin, in the case of complex data requests.
• Figure 3 illustrates a basic process that may be used by the sampler 18 to monitor performance as described above.
• the sampler initially initiates, or detects the initiation of, a client-server session. Once the session is initiated, the sampler logs some or all of the TCP messages of the session, including the message type and the time of receipt.
• stages of the session may be tracked (e.g., via a TCP state machine) as the messages are received (not shown).
• the message log is processed (preferably by the computational device 20, but alternatively by a separate computational device) to identify the various events or stages of the session (if not previously identified) and the associated response times.
• This analysis task may alternatively be performed in-whole or in-part in real time during session execution.
• network retry events may be counted as indicated above.
• the type of data analysis performed may be selected based on the location of the sampler 18 relative to the client and the server, as described above.
• the performance data may be uploaded to a local or remote database 30 or otherwise made available to system administrators, if multiple samplers are used to monitor the same session (e.g., one client-side and one server-side sampler), the performance data from such samplers may be correlated and combined for reporting purposes.
• the various performance measurements may be incorporated into one or more computer-generated reports made available to system administrators. In addition to the specific measurements discussed above, these reports may include such data as the average, maximum, and total network latency, and the average, maximum, and total server time. These values may be generated over a single session or over multiple sessions.
• the reports may also include scores indicating the levels of server bandwidth and network bandwidth detected.
• the various performance measurements may also be used to generate real time alert messages when performance problems are detected.
• the system and method of the present invention provide a simple mechanism for automatically measuring network server performance, together or separately. Because the performance parameters are determined based on non-application-dependent TCP messages and events such as those mentioned above, the system and method do not require use of a particular type of application, and can be used to monitor performance without regard to application type.

Applications Claiming Priority (3)

Publications (1)

Family

ID=22551083

Family Applications (1)

Country Status (5)

Cited By (1)

Families Citing this family (11)

Family Cites Families (3)

• 2000
  • 2000-09-18 CA CA002384187A patent/CA2384187A1/en not_active Abandoned
  • 2000-09-18 WO PCT/US2000/025540 patent/WO2001020918A2/en not_active Application Discontinuation
  • 2000-09-18 AU AU75888/00A patent/AU7588800A/en not_active Abandoned
  • 2000-09-18 JP JP2001524365A patent/JP2003530623A/ja active Pending
  • 2000-09-18 EP EP00965114A patent/EP1330889A2/de not_active Withdrawn

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events