JP2003530623A - Monitor server and network performance - Google Patents

Abstract

Summary The performance of a client-server network is measured by passively monitoring a TCP packet stream between a client and a server during a communication session. The packet stream may be monitored by a device local to the client, by a device local to the server, or both. By measuring the elapsed time between TCP messages associated with a selected event or phase of the session, separate response times and other performance parameters can be used to determine connection time, network latency, server response time, network bandwidth, and Calculated for networks, including server bandwidth, and for servers. Since the message stream is monitored at the application-independent protocol layer, regardless of the application-dependent events or messages, the method is not restricted to any particular application and has prior knowledge of the type of application data required by the client. Do not need.

Description

Detailed Description of the Invention

FIELD OF THE INVENTION The present invention is a system and method for determining server and network response times and other performance parameters in a client-server network by monitoring communication between the client and server. Regarding

BACKGROUND OF THE INVENTION Networks, including local area networks (LANs) and wide area networks (WANs), are becoming increasingly popular as the number of computing devices within an organization grows. Networks allow information to be shared between computing devices and as such are important for the ease and convenience of storing and accessing data throughout an organization. Networks are realized by connections between at least two computing devices or other network hardware devices. This connection may be present, for example, on a cable or wireless link and may be realized using optical signals, electrical signals, infrared signals or radio wave based signals (or a combination thereof). Data passes through this connection according to various protocols at various layers of the network. These protocols include, but are not limited to, Transmission Control Protocol (TCP), Internet Protocol (IP), Internet Packet Switching (IPX), System Network Architecture (SNA), Datagram Delivery Protocol (DDP), and so on. At the data link layer, such protocols include, but are not limited to, Ethernet, Token Ring, and Fiber Distributed Data Interface (FDDI).

Among these different types of protocols and network architectures,
There is a common need for monitoring the response time of both servers within the network and of the network itself. The need for such monitoring is not limited to any one particular type of network, as the client-server model is discovered across this different network architecture. Furthermore, the client-server model requires both an efficient server and an efficient network for high performance operation. In this way, pinpointing problems in the performance of either the network and / or the server is of great importance to the operation of the client-server system.

Existing tools and techniques for measuring the performance of client-server systems are flawed in many respects. For example, some technologies cannot differentiate server performance from network performance. In addition, many technologies are specific to a particular type of application and are therefore not suitable for monitoring generic client-server sessions. Furthermore, many technologies are application layer specific and as such can only monitor performance from the server itself. The present invention addresses these and other problems with the prior art.

SUMMARY OF THE INVENTION According to the present invention, a message stream between a client and a server is monitored from a location in the network to determine specific parameters of the performance of the network, the server, or both. Preferably, the message stream is a TCP or other application-specific message stream that is passively monitored by a computing device local to the client, a device local to the server, or both. The one or more specific performance parameters are measured by determining the amount of time between specific messages corresponding to a specific stage or event of the client-server session. Since these messages and events are application independent, performance parameters may be determined regardless of the type of application used in the session and without prior knowledge of the type of application data requested by the client. . In the preferred embodiment, assumed performance parameters include connect time, network latency, server response time, network bandwidth and server bandwidth.

One aspect of the present invention is thus a method of monitoring the performance of a client-server network from a location in the network. The method is
(A) monitoring the message stream of the network between the client and the server during the client-server session, and (b) detecting the first message of the message stream and the second message of the message stream, where the first message and The second message is selected to correspond to an application-independent event of the session, and (c) measures the elapsed time between the detection of the first message and the detection of the second message to determine network performance or server performance. Determining either parameter of performance. Performance is thereby measured regardless of the type of application used within the client-server session.

Another aspect of the present invention is that a client from a location on the network is
This is a system for monitoring the performance of server networks. The system comprises a computing device connected to a 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 that uses the message stream as monitored by a computing device to measure network and / or server performance.
The program module measures the time elapsed between the receipt of the first message of the message stream by the computing device and the receipt of the second message of the message stream by the computing device to determine a parameter of either network performance or server performance. To do. The first message and the second message correspond to selected application-independent events in the client-server session.

Another aspect of the invention is a system for monitoring the performance of a client-server network from a location in the network. The system comprises a computer connected to a 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. The system further comprises a program module that uses the message stream as monitored by a computer to measure network and / or server performance. The program module measures the time elapsed between the computer receipt of the first TCP message of the message stream and the computer receipt of the second TCP message of the message stream to determine a parameter of either network performance or server performance. Where the first TCP message and the second TCP message correspond to selected application-independent events within the session.

Detailed Description of the Preferred Embodiments The foregoing and other objects, aspects and advantages will be better understood from the following detailed description of the preferred embodiments of the invention with reference to the drawings.

The present invention provides a system and method for automatic measurement of client-server network performance that includes separate measurements of server performance and network performance. Performance measurements may be at or near the server, and / or
Or generated by measuring the time elapsed between certain messages between the client and server, as monitored at or near the client. As will be appreciated, the "meaning" of the measurement depends on the monitoring location, but the measurement is taken from virtually any location on the network from which the client-server message stream may be monitored. You can do it.

The method or process of the invention may be described as a series of steps or tasks implemented by a data processor, with the result that the process is:
It can be realized as hardware, software or firmware, or a combination thereof. In the preferred embodiment, the processes are implemented in software applications (programs) that run on one or more general purpose computers. Software applications may be written in any suitable programming language, such as C, C ++, and Java®.

In accordance with the present invention, messages between the client and the server can be sent to the TC to determine server and / or network response times and other performance parameters.
It is analyzed at the P layer, or other application independent protocol layer.
Various response times and other parameters are measured independent of application-specific information within the message stream. An important advantage of this method is that no prior knowledge of the type of application data required by the client is required. Data analysis is optional
And preferably by listening for TCP frames that indicate the state of the session between the client and the server. Preferably, the TCP messages are monitored by a hardware connection device connected to the network in a promiscuous mode in which all local network traffic passes through the connection device.

For simple requests from clients for a single type of data, analysis is performed on the data received through a single port. For more complex requests from clients containing multiple types of data, the data received through each port is preferably analyzed separately for server response time and / or network response time. Since such a complex request is actually a combination of simple requests, the server performance and / or the network performance can be determined by the decomposition of the received data. Additionally, as mentioned above, separate measurements may be performed at or near the server, and at or near clients on the network.

It will be understood that the principles and operation of the method and system according to the present invention may be better understood with reference to the drawings and accompanying descriptions, which are shown for illustrative purposes only and are not limiting.

Referring now to the drawings, FIG. 1 is a schematic block diagram of a system 10 for determining the performance of a network 12. As shown, the system typically includes a server 14 and a client 16 located apart from each other. The client and server are connected to network 12, which is preferably a network that supports TCP. Although generally depicted as a PC, the client device 16 may be, for example, a portable computer, WAP (Wireless Access Protocol) or other wireless telephone, data device, or any other that makes a request on the network as a client. Data processing device of this type. Similarly, the server 14 may be any type of data processing device or combination of data processing devices that serves such a request as a server.

The system also includes a sampling circuit 18 connected to the network 12. The sampling circuit 18 is preferably operated by a computing device or computer 20, also referred to as a “measurement computing device”, to distinguish the computing device 20 from the server 14 and the client 16. The measurement computing device 20 includes a network card 22 or other network connector hardware device. The network card 22 may listen for local traffic passing through or along the portion of the network 12 to which the measurement computing device is connected. The connection of the measurement computing device 20 to the network 22 is preferably a hardwired connection, but may alternatively be a wireless connection (eg in a wireless LAN environment). The sampling circuit may alternatively be implemented on the client device 16 or on the server device 14 (or both).

Computing device 20 may optionally (optionally) be located at or near server 14, or at or near client 16. In each case, network performance measurements may be made. Further, one computing device 20 may be located locally to the client 16 and another computing device 20 may be located locally to the server 14 so that the client-server session may be different (as described below). Monitored from both locations simultaneously (to obtain different types of measurements). When multiple devices are used to monitor the same session, the resulting performance measurements may be combined appropriately for analysis and reporting purposes.

In the promiscuous mode, the network card 22 determines whether the network card 1 has a network 1 regardless of whether the packet is specifically addressed to the network card 22 itself.
2. Receive all packets that pass through or along some of the two. Setting the network card 22 to operate in promiscuous mode is but one example of a mechanism for eavesdropping on network traffic flowing over the computing device 20 over the network 12. The adapted mechanism could be used, for example, to eavesdrop on network traffic for networks operating by microwave or fiber optic transmission, which do not operate with network interface cards. Such adaptations can be easily carried out by a person skilled in the art.

The robot 24 initiates a session with the server 14 on behalf of the client 16 and requests a web page or any type of markup language document or object to cause, for example, the transmission of data. Alternatively and preferably, the robot 24 is passive, in which case the information obtained by the network card 22 described in more detail below is passed to the robot 24. The robot 24 takes care of the initiation of such a session between the client 16 and the server 14 and monitors the transmission of data during the session. Session is TC
Being monitored at the P layer, the ability to reliably track sessions is independent of the particular type of client-server application being used.

The results obtained by the robot 24 regarding the various events or stages of the session and the amount of time that has elapsed during such stages are passed to a data buffer 28. The robot 24 is optionally and preferably implemented as an application software module, but alternatively as hardware (such as in a programmable ASIC or other integrated circuit device) or in firmware. Optionally, robot 24 is not used to perform the measurement if the measurement is performed by server 14 and / or client 16 instead.

The analyzer 26 also receives information obtained by the network card 22. The analyzer 26 calculates the amount of time it takes to reach each step, thereby determining the response time of the server 14 and / or the response time of the network 12. As will be described in more detail below with respect to the TCP protocol for data transmission, the analyzer 26 determines not only the time elapsed on receipt of each flag to determine various response times, but for each stage of the session obtained by the robot 24. Use flags or events. 2 shows the performance of the robot 24 and the analyzer 26 with respect to the TCP protocol for data transmission, but the response times are similarly measured for other protocols where communication during a session occurs at well-defined boundaries. You can do it.

The analyzer 26 preferably sends the analyzed data to a data buffer 28. The data buffer 28 optionally correlates the information between the analyzer 26 and the robot 24, preferably performing a complete analysis of the entire session for response time, latency and other parameters. Performance data (such as response time measurements) may optionally be collected from multiple sampling circuits 18 and stored in database 30. For example, multiple sampling circuits 18 could be deployed at selected client locations (eg, different office buildings, cities, or countries) and used to monitor performance as seen from such locations. . The resulting performance data generated by such sampling circuits may be reported to and collected within the central database 30 used to create online performance reports.

FIG. 2 illustrates an example client-server session and shows the measurements taken by sampling circuit 18 (or sampling circuits) in a preferred embodiment of the invention. In the illustrated embodiment, the client and server are T
Exchange packets with TCP commands or fields according to the CP protocol. As will be apparent, the particular performance parameters measured during the session depend on whether the sampling circuitry is local to the client, local to the server, or both. Certain steps or events in a session are numbered. The measurements shown on the client side of the drawing are taken using a computing device 20 that is local to the client so that the sampling circuit receives the packet at substantially the same time as it is transmitted or received by the client. To be done. The measurements shown on the server side of the drawing are taken using a computing device 20 that is local to the server so that the sampling circuit receives the packet substantially at the same time it is transmitted or received by the server. To be done.

At Event 1, the client sends a Sync (SYN) request to the server. At Event 2, the server responds to the client with a Synchronous Acknowledge (SYN / ACK) message, acknowledging both receipt of the SYN request and transmission of its SYN request. The time elapsed between the transmission of the SYN request by the client and the reception of the SYN / ACK response is the connection time (specific network latency measurement) if such connection time is measured at or near the client. is there.

At Event 3, the client sends an ACK message to the server. If the measurements are taken at or near the server, the connection time will be SYN / AC
It may be measured as the time elapsed between the transmission of the K response and the receipt of another ACK message (designated "server connection time" in Figure 2).

At Event 4, which occurs immediately after Event 3, the client sends a request for specific data, such as a GET command message, to the server. The server then responds to the client with an ACK message at Event 5.
The server sends such a response without processing the request and regardless of the type of application that has to process the request, so the server processing time (“kernel time”) Called) is usually very small.

The amount of time that elapses between the transmission of a GET message or other data request command by the client and the receipt of an ACK message from the server is measured at or near the client but Is the amount. Such measurement of network latency is optionally further refined to obtain a more accurate measure of network response time, measured at or near the client, minus the server kernel time. Good. As mentioned above, network latency is optionally measured at or near the server.

At Event 6, the server sends the requested data to the client in one or more data response (“R”) messages (four R messages shown). The time elapsed between the receipt of the GET message by the server and the transmission of the first "R" message by the server is the server response time or server latency as measured by the server. Creating the requested data can take a significant amount of processing time by the server. For example, for a single type of data, if the request is simple, then only one response message may be sent.

As further shown in FIG. 2, the response time of the server measures the time elapsed between receipt of an ACK message from the server and receipt of a first R message from the server for a location local to the client. May also be approximated by This approximation is based on the assumption that network latency is about the same for both of these messages.

As shown, a sequence of multiple consecutive R (Data Response) messages may be sent during Event 6 to transfer the requested data.
After the predetermined number of R messages have been sent, the server waits for an ACK message and the client sends an ACK message (event 7). Upon receiving this ACK message, the server restarts the transmission of the response message 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. As shown, the time elapsed (measured locally to the server) between the server transmission of the last R message in the sequence and the reception of the corresponding ACK message is indicative of the amount of network latency.

Another measurement that may optionally be taken, as shown in FIG. 2, is the time between consecutive R (data response) messages. The elapsed time period is the amount of time delay caused by the limited availability of bandwidth. This time period can be used to access network bandwidth when measured near the client. If measured near the server, this time period can be used to access the server bandwidth.

Each time the server responds to another GET message from the client, the server response time is preferably measured as described above. Additionally and / or alternatively, the server response time may be separately measured for the response each time data is sent to a different port.

An additional type of time measurement that may be performed on the server side is from receipt of an ACK message for the last R message to server transmission of a new R message to the client. This elapsed time period, 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 are:
May be taken later in the session.

Two other performance parameters that may be determined during a client-server session are the number of server retries and the number of network retries. Server retries occur when the server does not respond to a message from the client, such that the client must send the message again (not shown in Figure 2). Similarly, network retries occur when the client does not send an ACK message to the server so that the server must send the message again. If measurements are taken at or near the server,
The sampling circuit can distinguish between network and server retries by determining whether the packet was dropped by the server or the network. This is in contrast to conventional systems, which typically cannot distinguish between network and server retries.

After the transfer is completed, the server sends a FIN message to the client (not shown). The difference between the time when the last response is received by the client and the time when the FIN is received by the client adds some server processing time,
Another amount of network latency. In response to the FIN, the client sends a FIN / ACK message to the server (not shown) and then the server sends an ACK message back to the client (not shown). The sequence FIN (from the server), FIN / ACK (from the client), and ACK (from the server) is where in the case of complex data requests a particular data request session is terminated and a new session is started. It can be used to determine what is.

FIG. 3 illustrates the basic process that can be used by the sampling circuit 18 to monitor performance as described above. The sampling circuit first initiates a client-server session or detects the initiation of a client-server session. Once the session is initiated, the sampling circuit logs some or all of the TCP messages for the session, including message type and time of receipt. Other types of parameters such as message size may also be recorded. Further, the stage of the session may be tracked (eg, via a TCP state machine) as the message is received (not shown).
.

Once the session ends or times out, the message log (preferably by computing device 20, but alternatively by a separate computing device) (if not previously identified) Processed to identify various events or stages of the session and associated response times. Alternatively, this analysis task may be performed wholly or partially in real time during session execution. In addition to response time, network retry events may be counted as described above. The type of data analysis performed may be selected based on the location of the sampling circuit 18 relative to the client and server, as described above.

Once all of the performance measurements have been calculated, the performance data may be uploaded to a local or remote database 30 or otherwise made available to the system administrator. When multiple sampling circuits are used to monitor the same session (eg, one client-side sampling circuit and one server-side sampling circuit), performance data from such sampling circuits are interrelated for reporting purposes. May be associated with and combined with.

Various performance measures may be incorporated into one or more computer generated reports available to the system administrator. In addition to the specific measurements described above, these reports may include data such as average, maximum, and total network latency, and average, maximum, and total server time. These values may be generated in a single session or in multiple sessions. The report may also include a score indicating the level of detected server bandwidth and network bandwidth. Various performance measurements may also be used to generate real-time alert messages when performance problems are detected.

Thus, the system and method of the present invention provide a simple mechanism for automatically measuring network server performance, either together or separately. Since performance parameters are determined based on the application-independent TCP messages and events described above, the system and method do not require the use of any particular type of application and monitor performance regardless of application type. Can be used for

It will be appreciated that the above description is intended as examples only, and that many other embodiments are possible within the spirit and scope of the invention. The scope of the invention is defined only by the claims.

[Brief description of drawings]

FIG. 1 is a schematic block diagram of an exemplary system in accordance with the present invention.

FIG. 2 is a schematic block diagram of an exemplary session for performance parameter measurement in accordance with the present invention.

3 is a flow diagram of a process for measuring performance parameters of the type shown in FIG.

─────────────────────────────────────────────────── ─── Continued front page    (81) Designated countries EP (AT, BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, I T, LU, MC, NL, PT, SE), OA (BF, BJ , CF, CG, CI, CM, GA, GN, GW, ML, MR, NE, SN, TD, TG), AP (GH, GM, K E, LS, MW, MZ, SD, SL, SZ, TZ, UG , ZW), EA (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), AE, AG, AL, AM, AT, AU, AZ, BA, BB, BG, BR, BY, BZ, C A, CH, CN, CR, CU, CZ, DE, DK, DM , DZ, EE, ES, FI, GB, GD, GE, GH, GM, HR, HU, ID, IL, IN, IS, JP, K E, KG, KP, KR, KZ, LC, LK, LR, LS , LT, LU, LV, MA, MD, MG, MK, MN, MW, MX, MZ, NO, NZ, PL, PT, RO, R U, SD, SE, SG, SI, SK, SL, TJ, TM , TR, TT, TZ, UA, UG, UZ, VN, YU, ZA, ZW (72) Inventor Klein, Philip             Israel Jerusalem F term (reference) 5B089 GA11 GB02 JA36 KA13 MC06                       MC08 MC16                 5K030 GA14 HA08 MA04 MB12 MC08

Claims (43)

[Claims] 1. A method of monitoring the performance of a client-server network from a location on the network, comprising: (a) monitoring a message stream on the network between a client and a server during a client-server session, and (b). Detecting a first message of the message stream and an application-independent second message of the message stream, the first message and the second message being selected to correspond to an application-independent event of the session; and (c) network performance. Alternatively, it measures the elapsed time between the detection of the first message and the detection of the second message to determine either parameter of server performance and is independent of the type of application used in the client-server session. How performance is measured. 2. The method of claim 1, wherein (a) passively monitors the message stream. 3. The method of claim 1, wherein (a) passively monitors the message stream using a network card configured in promiscuous mode. 4. The method of claim 1, wherein in (a) the message stream is monitored at a network location local to the client and remote from the server. 5. The method of claim 1, wherein in (a) the message stream is monitored at a network location local to the server and remote from the client. 6. The method of claim 1, wherein the message stream is a transmission control protocol message stream. 7. The first message is a sync message from the client, the second message is a sync acknowledgment message from the server, and the first and second messages are such that the elapsed time represents the client connect time. The method of claim 1, detected at a network location that is local to the client. 8. The first message is a data request message from a client, the second message is an acknowledgment message sent by the server in response to the data request message, and the first message and the second message are elapsed times. The method of claim 1, wherein is detected at a network location local to the client so as to represent network latency. 9. The first message is an acknowledgment message received from the server in response to the data request message, the second message is a first data response message to the data request message, and the first message and the second message are The method of claim 1, wherein the elapsed time is detected at a network location local to the client so as to represent an approximate server response time. 10. The first message is a data response message of a sequence of consecutive data response messages transmitted by the server, the second message is a data response message immediately following the sequence, and the first message and the second message are: The method of claim 1, wherein the elapsed time is detected at a network location local to the client so as to represent a measure of network bandwidth. 11. The first message is a data response message of a sequence of consecutive data response messages transmitted by the server, the second message is a data response message immediately following the sequence, and the first message and the second message are The method of claim 1, wherein the elapsed time is detected at a network location local to the server such that the elapsed time represents a measure of server bandwidth. 12. The first message is a synchronous acknowledgment message from the server, the second message is an acknowledgment from the client to the synchronous acknowledgment message, and the first message and the second message are elapsed time server connection. Found in a network location local to the server, to represent time,
The method of claim 1. 13. The first message is a data request message from a client, the second message is a positive response from the server to the data request message, and the first message and the second message are elapsed time kernel time of the server. Detected at a network location local to the server,
The method of claim 1. 14. The first message is a data request message from a client, and the second message is a data response to the data request message.
The method of claim 1, wherein the message and the second message are detected at a network location local to the server such that the elapsed time represents the server response time. 15. The first message is the last message in the sequence of data response messages from the server, the second message is an acknowledgment from the client of receipt of the last message, and the first message and the second message. Is detected at a network location local to the server such that the elapsed time represents network latency. 16. The first message is a client acknowledgment of the last data response message in the sequence, the second message is the first data response message from the server in the immediately following sequence, and the first message and the second message are ,
The method of claim 1, wherein the elapsed time is detected at a network location local to the server to represent the restarted transmission server response time. 17. The method according to claim 1, further comprising repeating (b) and (c) at least once to generate a plurality of server response times, combine the plurality of server response times, and generate a total server response time. The method described. 18. Further, repeating (b) and (c) at least once to generate a plurality of network response times and combine the plurality of network response times to generate a total network response time or an average network response time. The method according to claim 1. 19. The method of claim 1, further comprising repeating (b) and (c) at least once to generate at least one network response time and at least one server response time. 20. The method of claim 1, wherein (a), (b) and (c) are performed separately from a client local location and a server local location to monitor the same session. 21. A system for monitoring the performance of a client-server network from a location on the network, the system being connected to the network, the client and server at an application independent protocol level during a client-server session. A computing device configured to monitor a message stream between and a program module that uses the message stream monitored by the computing device to measure network and / or server performance, the program module comprising: Receipt of a first message of a message stream by a computing device and a second message of the message stream to determine parameters of either network performance or server performance. Measuring the elapsed time between reception by the computing device, wherein the first message and the second message, a client - corresponding to an event that does not depend on the selected application in the server session system. 22. The system of claim 21, wherein the computing device is configured to passively monitor the message stream. 23. The system of claim 21, wherein the computing device passively uses the network card configured in promiscuous mode to monitor the message stream. 24. The system of claim 21, wherein the computing device is connected to the network locally to the client and remotely from the server. 25. The system of claim 21, wherein the computing device is connected to the network locally to the server and remotely from the client. 26. The system of claim 21, wherein the message stream is a transmission control protocol message stream. 27. The first message is a sync message from the client, the second message is a sync acknowledgment message from the server, and the computing device is local to the client such that the elapsed time represents the client connect time. 22. The system of claim 21, wherein: 28. The first message is a data request message from the client, the second message is an acknowledgment message sent by the server in response to the data request message, and the computing device determines that the elapsed time has network latency. 22. The system of claim 21, local to the client as represented. 29. The first message is an acknowledgment message received from the server in response to the data request message, the second message is the first data response message to the data request message, and the computing device is in progress. 22. The time is local to the client so that it represents an approximate server response time.
The system described in. 30. The first message is a data response message of a sequence of consecutive data response messages transmitted by the server, the second message is a data response message immediately following the sequence, and the computing device is configured to indicate that the elapsed time is within network bandwidth. Local to the client, as a measure of breadth,
The system according to claim 21. 31. The first message is a data response message of a sequence of continuous data response messages transmitted by the server, the second message is a data response message immediately following the sequence, and the computing device is configured to indicate that the elapsed time is the server time. 22. The system of claim 21, local to the server to represent a measure of bandwidth. 32. The first message is a synchronous acknowledgment message from the server, the second message is an acknowledgment from the client to the synchronous acknowledgment message, and the computing device causes the elapsed time to represent the server connect time. 22. The system of claim 21, local to the server. 33. The first message is a data request message from a client, the second message is an acknowledgment from a server to a data request message, and the computing device represents the elapsed time representing the kernel time of the server. 22. The system of claim 21, local to the server. 34. The first message is a data request message from a client, the second message is a data response to the data request message, and the computing device is local to the server such that the elapsed time represents the server response time. 22. The system of claim 21, wherein: 35. The first message is the last message in the sequence of data response messages from the server, the second message is an acknowledgment from the client of the receipt of the last message, and the computing device has elapsed time. 22. The system of claim 21, wherein is local to the server so as to represent network latency. 36. The first message is a client acknowledgment of the last data response message in the sequence, the second message is the first data response message from the server in the immediately following sequence, and the computing device restarts the elapsed time. 22. Local to the server to represent the transmitted transmission server response time.
The system described in. 37. The system of claim 21, wherein the elapsed time represents network latency. 38. The system of claim 21, wherein the elapsed time represents a server response time. 39. A system for monitoring the performance of a client-server network from a location on the network, wherein the system is connected to the network and a transmission control protocol between the client and the server during a session between the client and the server. A computer configured to passively monitor a (TCP) message stream; and a program module that uses the message stream as monitored by the computer to measure network and / or server performance. A program module receives a first TCP message of a message stream by a computer and a second T of the message stream to determine a parameter of either network performance or server performance. Measuring the elapsed time between the reception by the computer of the P message, the first 1TCP message and the second
A system in which a TCP message corresponds to an application-independent event selected within a session. 40. The system of claim 39, wherein the elapsed time represents network latency. 41. The system of claim 39, wherein the elapsed time represents a server response time. 42. The system of claim 39, wherein the elapsed time represents network bandwidth. 43. The system of claim 39, wherein the elapsed time represents server bandwidth.