Note: Descriptions are shown in the official language in which they were submitted.
CA 02384187 2002-03-06
WO 01/20918 PCT/US00/25540
SERVER AND NETWORK PERFORMANCE MONITORING
FIELD OF THE INVENTION
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.
BACKGROUND OF THE INVENTION
Networks, including local area networks (LANs) and wide area networks (WANsI,
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 thereofl.
Data is passed through this connection according to various protocols at
different layers of the network. These
protocols include but are not limited to, transmission control protocol (TCP),
Internet protocol (1P), Internet packet
exchange (IPXI, systems network architecture (SNAI, datagram delivery protocol
(DDP) and so forth. At the data link
layer, such protocols include, but are not limited to, Ethernet, token ring,
and fiber distributed data interface (FDDI).
Within these different types of protocols and network architectures, a common
need exists for monitoring
the response time of both servers within the network and the network itself.
Since the client-server model is found
throughout these different network architectures, the need for such monitoring
is not limited to any one particular
type of network. Furthermore, the client-server model requires both an
efficient server and an efficient network for
high performance operation. Thus, pinpointing any problems in the performance
of either the network andlor the
server is highly important for the operation of the client-server system.
Existing tools and technologies for measuring the performance of a client-
server system are deficient in a
number of respects. For example, some technologies cannot differentiate
between the performance of the server and
the performance of the network. In addition, many technologies are specific to
particular types of applications, and
are therefore are not suitable for monitoring generic client-server sessions.
In addition, many technologies are specific
to the application layer, 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
In accordance with the invention, 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
1
CA 02384187 2002-03-06
WO 01/20918 PCT/US00/25540
both. Preferably, 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. In a preferred
embodiment, 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.
Another aspect of the invention is a system for monitoring performance of a
client-server network from a
location on the network. 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 andlor 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.
Another aspect of the invention is a system for monitoring performance of a
client-server network from a
location on the network. 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. The system further comprises a program
module which uses the message stream
as monitored by the computer to measure performance of the network andlor 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.
2
CA 02384187 2002-03-06
WO 01/20918 PCT/US00/25540
BRIEF DESCRIPTION OF THE DRAWINGS
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, wherein:
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; and
FIG 3 is a flow diagram of a process for measuring performance parameters of
the type illustrated in FIG 2.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
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, andlor from a
location at or near the client. As will be
recognized, 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. In a preferred embodiment, 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.
In accordance with the invention, 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 andlor 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. Preferably, 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.
For simple requests from the client for a single type of data, the analysis is
performed on data received
through a single port. For more complex requests from the client involving
multiple types of data, data received
through each port is preferably analyzed separately for the response time of
the server andlor of the network. Since
such complex requests are actually a combination of multiple simple requests,
the performance of the server andlor of
the network can be determined by decomposition of the received data. In
addition, as previously mentioned, separate
measurements may be performed at or near the server, and at or near the client
on the network.
3
CA 02384187 2002-03-06
WO 01/20918 PCT/US00/25540
The principles and operation of a method and system according to the present
invention may be better
understood with reference to the drawings and the accompanying description, it
being understood that these drawings
are given for illustrative purposes only and are not meant to be limiting.
Referring now to the drawings, Figure 1 is a schematic block diagram of a
system 10 for determining the
performance of a network 12. As shown, 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. Although illustrated generally as a PC, 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. Likewise, 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.
The 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
environmentsl. The sampler could alternatively
run on the client device 16 or the server device 14 for bothl.
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
belowl. Where multiple devices are used to monitor the same session, the
resulting performance measurements may
be appropriately combined for purposes of analysis and reporting.
In promiscuous mode, 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. Alternatively and preferably,
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,
4
CA 02384187 2002-03-06
WO 01/20918 PCT/US00/25540
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.
The results obtained by robot 24, concerning the various events or stages of
the session and the amount of
time elapsed between such stages, are passed to a data buffer 28. Robot 24 is
optionally and preferably implemented
as an application software module, but is alternatively implemented as
hardware (such as within a programmable
ASIC or other integrated circuit device) or within firmware. Optionally, robot
24 is not used to perform the
measurements, which instead are performed by the server 14 andlor 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 andlor 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 (response
time measurements, etc.) may
optionally be collected from a plurality of samplers 18 and stored in a
database 30. For example, 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.
Figure 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. In the illustrated
embodiment, the client and the server
exchange packets with TCP commands or fields according to the TCP protocol. As
will be apparent, 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.
At event 1, the client sends a synchronize ISYN) request to the server. At
event 2, the server replies to the
client with a synchronize acknowledgement (SYNIACK) 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 SYNIACK reply by the client is the connect time (a specific network
latency measurement), when such connect
time is measured at or near the client.
5
CA 02384187 2002-03-06
WO 01/20918 PCT/US00/25540
At event 3, 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 SYNIACK reply and
receipt of another ACK message (labeled "server connect time" in Figure 2).
At event 4, which occurs shortly after event 3, the client sends a request to
the server for particular data,
S such as a GET command message. The server then 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
ACK message is normally very low.
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. As previously described, network latency is also 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 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.
As further shown in Figure 2, 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.
As illustrated, a sequence of multiple consecutive R (data response) messages
may he sent during event 6 to
transfer the requested data. After some predetermined number of R messages
have been sent, the server waits for,
and the client sends, an ACK message (event 71. Upon receiving this ACK
message, 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. As illustrated, 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.
As illustrated in Figure 2, 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.
Each time the server responds to another GET message from the client, the
server response time is
preferably measured as described above. Additionally andlor alternatively,
each time data is sent to a different port,
6
CA 02384187 2002-03-06
WO 01/20918 PCT/US00/25540
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 21. Similarly, 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.
After the transfer is complete, 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. In response to the FIN, the
client sends a FINIACK message to the server (not shown), and the server then
returns an ACK message to the client
(not shownl. The sequence of FIN (from the served; FINIACK (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.
Other types of parameters such as the message size may also be recorded. In
addition, the stages of the session may
be tracked (e.g., via a TCP state machine) as the messages are received (not
shown).
Once the session ends or times out, 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. In addition to the response
times, 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.
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 system
administrators. If multiple samplers are used to
monitor the same session (e.g., one client-side and one server-side sampled,
the performance data from such samplers
may be correlated and combined for reporting purposes.
7
CA 02384187 2002-03-06
WO 01/20918 PCT/US00/25540
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.
Thus, 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.
It will be appreciated that the above descriptions are intended only to serve
as examples, and that many
other embodiments are possible within the spirit and the scope of the present
invention. The scope of the invention is
defined only by the following claims.
8
