IEEE TRANSACTIONS ON PARALLEL AND DISTRIBUTED SYSTEMS, VOL. 22, NO.

5, MAY 2011 773

Measuring Client-Perceived Pageview

Response Time of Internet Services
Jianbin Wei, Member, IEEE Computer Society, and Cheng-Zhong Xu, Senior Member, IEEE

Abstract—As e-commerce services are exponentially growing, businesses need quantitative estimates of client-perceived response
times to continuously improve the quality of their services. Current server-side nonintrusive measurement techniques are limited to
nonsecured HTTP traffic. In this paper, we present the design and evaluation a monitor, namely sMonitor, which is able to measure
client-perceived response times for both HTTP and HTTPS traffic. At the heart of sMonitor is a novel size-based analysis method that
parses live packets to delimit different webpages and to infer their response times. The method is based on the observation that most
HTTP(S)-compatible browsers send significantly larger requests for container objects than those for embedded objects. sMonitor is
designed to operate accurately in the presence of complicated browser behaviors, such as parallel downloading of multiple webpages
and HTTP pipelining, as well as packet losses and delays. It requires only to passively collect network traffic in and out of the monitored
secured services. We conduct comprehensive experiments across a wide range of operating conditions using live secured Internet
services, on the PlanetLab, and on controlled networks. The experimental results demonstrate that sMonitor is able to control the
estimation error within 6.7 percent, in comparison with the actual measured time at the client side.

Index Terms—Client-perceived service quality, monitoring and measurement, pageview response time, secured Internet services.

1 INTRODUCTION

W ITH recent technology developments, secured Internet

services are the foundation for various e-commerce
services, such as online banking, shopping, auctions, and
payments. For these e-commerce services, the Internet is a
highly competitive environment. Clients have many choices
when they are seeking quality services. Whenever an e-
commerce service cannot meet their quality requirements,
they can turn to elsewhere much more easily than in
traditional business environments. This makes it especially
critical for e-commerce service providers to offer quantifiable
service quality to attract new clients while retaining old ones.
Client-perceived response time is a key measure of
client-experienced service quality. In deciding whether to
continue using one e-commerce service, 46 percent clients
want to have quick checkout process and 40 percent want to
have fast pageview response time [26]. Early experiments at
Amazon even showed a one percent sales loss for an
additional 100 ms delay [13]. Therefore, obtaining quanti-
tative measures of the response times in a timely and cost-
effective manner is fundamental to manage e-commerce
services across a diverse and rapidly changing client
population. By obtaining the response times, businesses
might employ techniques to match different clients’
requirements for service qualities [19], [33], [35]. For
example, in [33], [35], [36], the authors proposed mechan-
isms to dynamically allocate resources to different clients to
. J. Wei is with Yahoo! Inc, Sunnyvale, CA 94089.
E-mail: jianbinw@yahoo-inc.com.
. C.-Z. Xu is with the Department of Electrical and Computer Engineering,
Wayne State University, Detroit, MI 48202. E-mail: czxu@wayne.edu.
Manuscript received 31 May 2009; revised 1 Feb. 2010; accepted 8 May 2010;
published online 16 June 2010.
Recommended for acceptance by D. Turgut.
For information on obtaining reprints of this article, please send e-mail to:
tpds@computer.org, and reference IEEECS Log Number TPDS-2009-05-0247.
Digital Object Identifier no. 10.1109/TPDS.2010.131.
1045-9219/11/$26.00 ß 2011 IEEE
support their requirements on response times. By obtaining
the response times promptly, businesses can also quickly
identify problems, get them fixed, reduce downtime costs,
and thus, maintain high service availability. For example, if
the response time is large while network latency is small,
the service providers would expect issues in the back-end
servers. Webserver logs can be used to determine the exact
objects that are requested for troubleshooting.
Measuring client-perceived response time at the server
side is challenging. In general, the client-perceived response
time of a webpage is the retrieval time of the whole page,
including the container object (e.g., an HTML file) and all of
its embedded objects, such as images. Hence, a key to the
measurement of pageview response time is to delimit
different pages when they are being downloaded simulta-
neously by different clients via HTTP requests and
responses. HTTP protocol itself, however, does not provide
any methods for such page delimitations. Moreover, page
delimitations need to be conducted in the presence of
complicated browser behaviors, such as parallel down-
loading of multiple webpages and HTTP pipelining, as well
as packet losses and delays.
More importantly, for secured Internet services, such
response-time measurements must be conducted without
decrypting HTTPS messages. This is particularly important
for web hosting providers that are responsible for maintain-
ing the infrastructure of various Internet services for
businesses but are prohibited from parsing the network
traffic in and out of these services. Even for network
administrators of these services, they are allowed to parse
decrypted contents only in some special cases to prevent
potential leaks of clients’ personal information, such as
passwords and credit card numbers. Furthermore, for
secured Internet services where the encryption is conducted
by webservers, it is impossible to analyze decrypted
HTTPS messages without modifying the structures of these
Published by the IEEE Computer Society
774 IEEE TRANSACTIONS ON PARALLEL AND DISTRIBUTED SYSTEMS,
webservers. Such modification would limit the scalability of
the measurement and render the system hard to be deployed.
There are many response-time measurement techniques
with different characteristics. They include active samplings
from particular network locations [12], [16], instrumentation
of webpages [25] or webservers [1], offline HTTP traffic
analysis [5], [15], and online HTTP traffic analysis [5], [21]. In
particular, E2E [5] and ksniffer [21] are able to measure
pageview response time at the server side in a nonintrusively
manner. However, none of them is able to measure the time
for secured Internet services nonintrusively. They fall short,
in one aspect or the other, in capability, accuracy, intrusive-
ness, and real-time availability of the measurements. More
importantly, they all need to decrypt HTTPS messages.
In this paper, we present sMonitor for measuring client-
perceived response times for both secured and unsecured
Internet services nonintrusively. At the heart of sMonitor is
a novel packet-size-based analysis method that parses live
packets to delimit different webpages retrieved by different
clients at the same time and infers their response times. The
analysis method is based on the observation that most
HTTP(S)-compatible browsers send significantly larger
requests for container objects than those for embedded
objects. Note that the analysis method is based on protocol
features of HTTP and HTTPS. Therefore, although the use
of web services evolves very quickly, it does not affect the
validity of the method as long as the underlying protocols
do not change the features, which is the case for HTTP/
1.1bis [8]. On the other hand, sMonitor actually is useful in
monitoring such evolving and can help service providers to
adopt to the evolving.
Comparing with existing techniques, sMonitor offers a
number of unique benefits.
sMonitor works for secured Internet services with-
1.
out requiring any modifications, such as embed-
ding codes in webpages or decoupling encryption
components from webservers. This feature would
simplfy the deployment of sMonitor in real
environments.
2. sMonitor accurately measures client-perceived re-
sponse times by capturing different browser beha-
viors, such as parallel downloading of multiple
webpages and pipelining of HTTP requests. More-
over, it is agile to the change of client access patterns.
3. sMonitor measures response times for all real clients
who access the monitored service. It provides a
much more complete view of the service perfor-
mance than active sampling that uses customized
browsers from a few locations that generally have
better network connectivities than the real world.
We conducted comprehensive experiments across a
wide range of operating conditions using live secured
Internet services, on the PlanetLab, and on controlled
networks. The experimental results suggested that
sMonitor should be accurate in terms of both response
time and page delimitation. The measurement errors were
kept within 6.7 percent (or 210 ms) in comparison with the
response times measured at the client sides. Although
network traffic was encrypted, no more than 18 percent
webpages would be falsely delimited. In contrast, ksniffer
VOL. 22, NO. 5, MAY 2011
Fig. 1. The architecture of sMonitor.
reported a measurement error of 3 percent to 5 percent
[21]. But it is limited to unsecured HTTP traffic.
The rest of this paper is organized as follows: In Section 2,
we present the architecture of sMonitor. Section 3 discusses
the design of sMonitor and the size-based analysis method
for page delimitations. Section 4 gives the evaluation
methodology. Section 5 shows the experimental results. In
Section 6, we survey existing techniques and products and
discuss their merits and limitations. Section 7 concludes this
paper with remarks on the limitation of sMonitor and
possible future work.
2 OVERVIEW OF sMONITOR ARCHITECTURE
In general, client-perceived pageview response time of an
Internet service corresponds to the duration from the time
when the client clicks/inputs the address of its web page to
the time when all objects of the webpage are retrieved. We
design sMonitor to measure the time for Internet services in a
nonintrusive manner so that it can be deployed without
needs for any modification to existing Internet services. As
shown in Fig. 1, sMonitor runs as a stand-alone application,
keeps capturing packets in and out of the monitored service.
It analyzes the traffic using a size-based analysis method to
infer client-perceived pageview response times. sMonitor
works for both secured HTTPS and unsecured HTTP traffic.
Because of its unique strengths in the treatment of HTTPS
traffic, we elaborate the system architecture details in the
context of secured Internet services.
sMonitor consists of three modules. A packet sniffer
passively collects live network packets using pcap (libpcap
on Unix-like systems or WinPcap on Windows). A packet
analyzer then parses the packets to extract HTTP transac-
tion information, such as HTTP request sizes, and passes
them to a performance analyzer. To obtain such informa-
tion, the analyzer only needs TCP/IP and SSL/TLS record
headers, which are not encrypted. The parsed packets are
discarded to reduce storage requirements. Based on the
HTTP transaction information, the performance analyzer
uses the packet-size-based analysis method to delimit pages
and measure their response times.
In sMonitor, the control flow is as far as possible data
driven: The packet processing loop is driven by the presence
of packets. It is composed of three parts. The first part is to
process packets for connection establishments and releases.
Upon capturing a SYN packet from a client, sMonitor
creates a new connection object. If the packet is from a new
client, sMonitor also creates a new client object. If the
packet is for connection releases, e.g., a FIN or RST packet,
the corresponding connection will be deleted. The second
WEI AND XU: MEASURING CLIENT-PERCEIVED PAGEVIEW RESPONSE TIME OF INTERNET SERVICES
Fig. 2. Retrievals of multiple pages and embedded objects using
pipelined requests over multiple connections.
part processes server responses. sMonitor classifies a server
packet with nonempty application data as a server
response. A response packet is identified as the end of
the response if no further response packets are captured
within a timeout period or if a new request arrives over the
same connection after it. The third part of packet proces-
sing is for client requests. It parses TCP/IP and SSL/TLS
record headers to obtain HTTP request sizes. After that,
combining with identified response ends, it uses the
packet-size-based analysis method to delimit pages and
infers their response times.
Page retrieval is a complicated process. A browser may
retrieve multiple pages at the same time using pipelined
HTTP requests over multiple persistent TCP connections.
Fig. 2 shows the HTTP protocol for accessing a web page
containing multiple embedded objects. It starts with a
request for the page container object, followed by requests
for the embedded objects. Essential to the inference of
pageview response times is identification of the requests for
containers in the traffic flow. This is nontrivial, because a
client can have many different ways (persistent versus
nonpersistent connections, pipelining, parallel download-
ing, etc.) to access the webpages of an Internet service. The
request and response packets with respect to different
webpages are mixed in the captured traffic, which makes
the issue of page delimitation challenging. At the heart of
sMonitor is a packet-size-based analysis approach to
determine retrieval beginning and end of a webpage in a
traffic flow without decrypting HTTPS messages.
The overhead of sMonitor is small because only TCP/IP
and SSL/TLS record headers need to be captured and
analyzed. In general, TCP/IP headers are 40 bytes and the
SSL/TLS record headers are only 5 bytes. In this work, we
designed sMonitor as a user-space application for good
portability. To further improve sMonitor’s performance, it
can be easily implemented in the kernel space. For example,
in [21], the authors reported that their ksniffer approach
had a capacity near gigabit traffic rates without packet
losses. We believe that sMonitor should have the same
capacity as or even higher capacity than ksniffer. This is
because ksniffer requires to parse packets up to HTTP layer
while sMonitor does not. Because the focus of this paper is
775
on sMonitor’s accuracy, we will not present the detailed
discussion and evaluation of sMonitor’s capacity. It is worth
noting that the accuracy of sMonitor is not affected by the
capacity when there is no loss in capturing packets.
3 PACKET-SIZE-BASED ANALYSIS FOR PAGE
DELIMITATION
A key challenge in inferring client-perceived pageview
response times from captured packets is page delimitation.
In this section, we present the packet-size-based analysis
method to identify the requests for container objects in page
delimitation. Let r0k denote the HTTP request for the
container object of webpage k. Then r0k and r0kþ1 help delimit
the retrieval beginning and end of page k, respectively.
3.1 The Size-Based Analysis Method
Our design of the size-based analysis method is based on an
observation of HTTP(S)-compatible browser behaviors,
which we first reported in [34]: The request for the container
of a page is normally significantly larger than the follow-up
requests for its embedded objects, and the follow-up
requests often have similar sizes. An HTTP request message
begins with a request line, followed by a set of optional
headers and an optional message body. The large size
difference between r0k and the request rik for embedded
object i is mainly because of the following reasons:
1. In HTTP/1.0 and HTTP/1.1, the Accept header is
designed to specify certain media types which are
acceptable for the response. To be protocol-compa-
tible, most browsers use the default standard
Accept header in the first request r0k for a page to
indicate as many as possible acceptable types. On
the other hand, rik uses Accept header to indicate
that the request is specifically limited to a small set
of desired types and the header is smaller than the
default standard one. For example, through our
experiments, in IE, r0k has a default Accept header
that can be 161 bytes larger than that in rik when
certain applications, such as Microsoft Office and
Adobe Flash, add their identifications to the default
header. We also examined the source code of Firefox
and Mozilla and found that the size difference could
be as large as 93 bytes.
2. For static web objects, the request lines in r0k and rik
tend to have limited sizes for easy administrations of
a website. For dynamically generated objects, their
URLs often follow the same pattern and the sizes are
very close to each other.
3. In general, for HTTP headers, the only difference
between requests r0k and rik is the Accept headers. In
the case where cookies are used, the first request
from a client for the website may be smaller than
others since it does not contain a Cookie header while
others do. The first request, however, is normally for
the container of a webpage. Therefore, the size
difference is a good method to differentiate requests
for container objects and for embedded objects.
4. Across a wide variety of measurement studies, the
overwhelming majority of web requests do not have
776 IEEE TRANSACTIONS ON PARALLEL AND DISTRIBUTED SYSTEMS,
Fig. 3. Structure of the packet analyzer.
message bodies. They use the GET method to
retrieve webpages and invoke scripts [9], [22].
Based on the observation of HTTP(S)-compatible brow-
ser behaviors, we design the size-based analysis method.
Let xn denote the size of the nth HTTP request, which
includes the HTTP method header and all other HTTP
header fields. The second derivative of the HTTP request
size function fðxÞ can be approximated as
f 00 ðxn Þ ffi ðf 0 ðxn þ h=2Þ  f 0 ðxn  h=2ÞÞ=h
¼ ðfðxnþ1 Þ  2fðxn Þ þ fðxn1 ÞÞ=h2 þ Oðh2 Þ;
where h is the step size. Since the function is discrete, let h
be 1, we assert that
f 00 ðxn Þ ffi xnþ1  2xn þ xn1 :
If f 00 ðxn Þ < 0, then fðxÞ is in a concave shape and it has a
relative maximum value at xn . Let t denote a configurable
threshold of the size difference between r0k and rik . We set a
page delimitation policy as “the request n is identified as r0k
if f 00 ðxn Þ is less than t.”
The selection of t should maximize the number of
correctly identified requests for container objects, and
meanwhile minimizing the number of false positive ones
that would otherwise impair the accuracy of sMonitor.
Notice that in IE and Firefox, r0k has Accept header that is
normally 161 bytes and 93 bytes larger than the one in rik ,
respectively. Considering the possible difference between
other headers in r0k and rik , we set t to 60 bytes by default
in sMonitor. This setting is then used in all of our test cases
and we find that this is a good choice. In general, for a
service, t should be set based on the shares of different
browser clients use to access the service since these
browsers have different behaviors. For example, if most
clients use IE then t can be smaller than 60 because IE has
large Accept header in r0k . Moreover, there is no one
optimal t for all services because different services have
different clients.
sMonitor keeps track of all clients and their activities
using a hash table, which is indexed by a hash function over
the IP address of each client. Fig. 3 shows the structure of
the table. Each client object in the hash table maintains a list
of active connections. It also contains an array of HTTP
transactions that need to be processed by the performance
analyzer. The data structures of client, active connection,
and HTTP transaction are presented in Fig. 4.
There are several issues we need to address in the design
of sMonitor. First, we must consider the difference between
the time of sending packets from clients or servers and the
time of receiving them by servers or clients. When a client
retrieves a page, if there exist no active connections, the
VOL. 22, NO. 5, MAY 2011
Fig. 4. Data structures used in the packet analyzer.
client must first establish a connection. As shown in Fig. 2,
the request r0k is generally sent right after the last step of the
three-way handshake. Therefore, there is at least 1.5 round-
trip time (RTT) gap before the server receives the first
packet of the request r0k . In the case where the request r0k is
transmitted over an existing connection, the gap is 0.5RTT.
Similarly, there is also a 0.5RTT gap between the time the
server sends the last packet of a response and the time the
client receives it. To take into account these time gaps,
sMonitor records the RTT for every client using an
exponentially weighted moving average of the difference
between a packet and its acknowledgment in the same
manner as TCP [24].
Second, in sMonitor, the end of a page is identified as the
last response packet received before the arrival of another
request for a container object. The request can be trans-
mitted over the same or a different connection. This
identification method may cause measurement lags or
delayed page delimitations because there exists a time gap
between the end of a webpage and the arrivals of requests
for another one. Furthermore, this time gap may be as long
as a few minutes. sMonitor addresses this issue using a
configurable timeout mechanism: If there is no packet
transmitted between the client and the server for the
timeout period, sMonitor infers that the page is ended. In
sMonitor, we set the default timeout period to 5 s because it
is often regarded as a threshold of acceptable pageview
response time [3]. To implement the timeout mechanism,
sMonitor records the latest response time in the “last packet
time” field. sMonitor then scans this field periodically to
check if any packet is transmitted between the client and the
server within the timeout period.
Third, sMonitor also needs to deal with the effects of
HTTP pipelining, in which multiple requests can be sent to
the server without waiting for the completion of prior
requests. sMonitor identifies a client message as pipelined
HTTP requests for multiple embedded objects if the
message is the same as or larger than 1,500 bytes (the
maximum transmission unit of Ethernet). Such an identifi-
cation method is based on two observed facts. First, past
studies showed more than 90 percent of the requests were
less than 1 KB bytes and most large requests were for
services, such as web-mail, that have large message bodies
[30]. Second, as pointed out in [21], in most cases, only
requests for embedded objects are pipelined.
Meanwhile, sMonitor needs to be resilient to parallel
downloading. During parallel downloading, multiple pages
are retrieved at the same time and their requests are
intertwined. This might cause false identifications of page
ends. As an example, assuming that a client retrieves pages k
and k þ 1 using parallel downloading, in sMonitor, request
WEI AND XU: MEASURING CLIENT-PERCEIVED PAGEVIEW RESPONSE TIME OF INTERNET SERVICES
r0kþ1 is identified as the retrieval beginning of page k þ 1. All
requests following r0kþ1 would be then identified as the
requests for embedded objects in page k þ 1. Due to parallel
downloading, however, requests for the embedded objects in
page k may be sent after r0kþ1 . The measured response time of
page k becomes smaller than that perceived by the client
while that of page k þ 1 becomes larger. As we shall see in
Section 5.1, sMonitor is still able to measure average response
time perceived by the client accurately.
In summary, sMonitor records RTTs to address the delay
between the time clients send requests and the time servers
receive these requests. It uses the configurable timeout
mechanism to measure response time promptly. Also
requests that are the same as or large than 1,500 bytes are
determined to be pipelined requests for embedded objects. At
last, we demonstrate the accuracy of sMonitor is acceptable
even with significant percentage of parallel downloading.
3.2 HTTPS Request Size Inference
In general, secured Internet services use either SSL protocols
or TLS protocols to encrypt HTTP messages transmitted
between clients and servers. Since these protocols are similar,
our discussion focuses on SSL protocols and it also applies to
TLS protocols unless specified explicitly.
In SSL record protocol, an HTTP message is first
fragmented into blocks of 214 bytes or less, which are then
optionally compressed. A message authentication code
(MAC) over a compressed fragment is then calculated using
HMAC MD5 or HMAC SHA-1 algorithms [14] and ap-
pended to the fragment. After that, the compressed fragment
and the MAC are encrypted using a symmetric encryption
algorithm. The final step is to attach a 5-byte plaintext record
header to the beginning of the encrypted fragment. The SSL
record fragment is then passed to lower protocols, such as
TCP, for transmissions. In this way, with the support of SSL
protocols, the HTTP message is transmitted with guarantees
of its secrecy, integrity, and authenticity.
As is known, it is extremely hard to hide information
such as the size or the timing of a message [7]. In [31], the
authors developed an approach to estimate the object size in
an encrypted HTTPS response message. Because it assumed
a minimal response message size of 4 KB, their approach
cannot be applied to analyze the HTTPS request messages
of a few hundreds bytes. In the following, we present our
experiments for inferring the size of an HTTP request from
its corresponding encrypted HTTPS one. In the experi-
ments, we sent HTTP requests over SSL/TLS protocols to
an HTTPS webserver using Microsoft’s WinInet library. The
sizes of these HTTP requests were known before being
encrypted. We then captured the corresponding HTTPS
messages and measured their sizes. There are three issues
worth noting in the design of the experiments.
1. To send HTTP requests with arbitrary sizes, we set
their Accept headers to meaningless characters in
our experiments. HTTP/1.1 specifies that a webser-
ver should send a 406 (“not acceptable”) response if
the acceptable content type set in a request’s
Accept header cannot be satisfied directly. We
found that, however, most webservers, including
Microsoft Internet Information Services and Apache
777
Fig. 5. Determining the size relationship between HTTP and HTTPS
messages.
webservers, just ignore the unrecognized Accept
header and send back the default response. Thus,
the meaningless Accept headers we used did not
bias our experimental results.
2. In order to evaluate different protocols, encryption
algorithms, and MAC algorithms, we modified the
settings of a Windows system according to [17]. This
is important because otherwise only one set of
algorithms will be used. For example, in IE 6.0,
TLS protocols are disabled, and in IE 7.0 RC1, they
are enabled by default; in addition, RC4 is always
used by IE as the first option for the encryption
algorithm and MD5 is used as the MAC algorithm.
3. To ensure that we are able to capture the corre-
sponding HTTPS message of an HTTP request, we
disabled the local cache. To achieve that, we passed
the flags INTERNET_FLAG_NO_CACHE_WRITE
and INTERNET_FLAG_RELOAD to the function
HttpOpenRequest().
We conducted experiments with HTTP requests ranging
from 100 through 2,000 bytes. The sizes of the HTTPS
messages were obtained by checking their record headers of
the first SSL/TLS record fragments with the content type as
application data. To demonstrate how we determine HTTP
request sizes from HTTPS messages clearly, in Fig. 5, we only
depict the results where the sizes of the HTTP requests
ranging from 300 through 350 bytes. In the figure, the first
half of each legend, RC4 or 3DES, denotes the cipher suite
used and the second half, e.g., MD5 or SHA, is the MAC
algorithm. We determine the cipher suite used between the
client and the server by checking the handshake messages for
session establishments. These messages are not encrypted.
From Fig. 5, we observe that the size difference between
an HTTP request and its corresponding HTTPS request is
always 16 bytes for RC4_MD5 and 20 bytes for RC4_SHA.
This is because of two reasons. First, RC4 is a stream cipher.
Thus, the ciphertext has the same size as the plaintext.
Second, MD5 calculates a 16-byte MAC and SHA calculates
a 20-byte MAC.
In the case of 3DES_SHA, we can determine the size of an
HTTP message within 8 bytes from the size of the
corresponding HTTPS message. This is because 3DES is a
block cipher with a block size of 8 bytes. For example, for a
360-byte HTTPS message, since there exists a byte to record
the padding size, only another zero or seven padding bytes is
needed to make the total an integral multiple of 8 in 3DES.
Considering the 20-byte MAC calculated by SHA, the HTTP
message therefore ranges from 332 through 339 bytes. Such a
determination can also be observed from Fig. 5.
778 IEEE TRANSACTIONS ON PARALLEL AND DISTRIBUTED SYSTEMS,
Furthermore, in SSL protocols, the padding added to an
HTTP message prior to the encryption operation is the
minimum amount required so that the total size of the data
to be encrypted is a multiple of the cipher’s block size. In
contrast, TLS protocols define a random padding mechanism
so that the padding can be any amount that results in a total
that is a multiple of the cipher’s block size, up to a
maximum of 255 bytes. It aims to frustrate attacks based on
a size analysis of exchanged messages. From Fig. 5, we can
see that the random padding is not implemented in IE 6.0
and 7.0 RC 1 for TLS protocols. We can draw the same
conclusion for Firefox.
The compression operation can change the size of an
HTTP request. Such a change might affect the accuracy of
the size-based analysis method presented in Section 3.1.
From Fig. 5, however, we observe that the compression
operation is not performed. This is because no default
compression algorithm is specified in SSL/TLS protocols.
In summary, we can determine the size of an HTTP
request from the corresponding HTTPS request in the case of
stream ciphers, such as RC4, or an estimation within a block-
size difference in the case of block ciphers, such as 8 bytes for
DES and 3DES.
4 EVALUATION METHODOLOGY
We conducted experiments under a wide range of operating
conditions using live secured Internet services, on the
PlanetLab, and on the controlled networks to evaluate the
accuracy of sMonitor. We evaluated the accuracy in three
aspects. The first is the ability to accurately infer pageview
response times perceived by clients. The second is the
ability to correctly delimit different webpages. The third is
measurement lag from the time when the last object of a page
is delivered to the time the page is delimited by sMonitor.
The measurement lag is mainly determined by when the
request for container object of next page arrives and the
timeout mechanism used in sMonitor. For example, when
the response of the last object in the page is retrieved,
sMonitor cannot decide if the page is completely down-
loaded until it detects the arrival of requests for another page,
or the timeout period has passed. Measurement lag exists in
other response-time monitors, such as ksniffer [21] and EtE
[5]. For example, ksniffer used a timeout mechanism or the
arrival of a request for a container object to identify the end of
a page retrieval. There exists time gaps between the ends of
page retrievals and their identifications.
In the experiments, sMonitor captured network traffic in
and out of monitored services, analyzed packets, and then
inferred pageview response times. We used an Apache
webserver with the support of OpenSSL to provide secured
Internet services. In addition, the Apache webserver also
supports HTTP/1.1.
We used SURGE [2] to generate emulated web objects, in
which there were 2,000 unique objects. Similar to [21], we
also made minor changes to SURGE to reflect more recent
work on web traffic characterizations [9], [30]. That is, the
maximum number of embedded objects in a given page was
set to 100 instead of 150; the percentages of base, embedded,
and loner objects were changed from 30 percent, 38 percent,
and 32 percent to 42 percent, 48 percent, and 10 percent,
VOL. 22, NO. 5, MAY 2011
respectively. In total, there were 1,041 container objects and
959 embedded objects.
Furthermore, we made following enhancements to
SURGE to mimic behaviors of real-world browsers:
1. To support secured Internet services, we updated
SURGE with OpenSSL 0.9.8 (www.openssl.org).
2. We enhanced SURGE to mimic behaviors of IE and
Firefox so that requests for container objects may
have large Accept headers.
3. We updated SURGE to support parallel downloading
by establishing another two persistent TCP connec-
tions for page retrievals.
4. We added the support of HTTP pipelining to SURGE
by following the default behaviors of Firefox since it
is the most widely used browser that has imple-
mented HTTP pipelining.
5. We followed HTTP/1.1 to set SURGE to use two
parallel persistent TCP connections to retrieve
webpages and their embedded objects.
6. In the enhanced SURGE, each user equivalent (UE)
binds to a unique IP address using IP aliasing on the
client machines. This makes each client machine
appear to the server as a collection of unique clients.
7. We updated SURGE so that each UE would send
requests for a page’s embedded objects only after the
container object is received.
8. The enhanced SURGE also records the retrieval time of
every webpage as the client-perceived response time.
In experiments with live secured Internet services, we
used IE and Firefox to retrieve 44 webpages from several
different Internet services, including online banking sites.
We recorded their retrieval times manually. Because it was
infeasible for us to deploy sMonitor near those servers, we
placed sMonitor on the client side to measure response
times. We believe that such a placement of sMonitor has
little effect on our accuracy evaluation since the key for the
measurement is the identifications of retrieval beginnings
and ends of individual pages [5]. In the experiment, we also
consider network transfer times from the client to servers to
simulate measuring from server-side and use sMonitor to
handle the variance of RTT during the experiment.
We also conducted experiments on the PlanetLab to
evaluate sMonitor’s accuracy in a real-world environment.
In these experiments, clients resided on nine geographically
diverse nodes: Cambridge, Massachusetts, San Diego,
California, and Cambridge, United Kingdom. The webser-
ver was setup in Detroit, Michigan. It was a Dell PowerEdge
2450 configured with dual-processor (1 GHz Pentium III)
and 512 MB main memory. We connected the server to the
Internet via a 100 Mbps network card. During these
experiments, the RTTs between the server and the clients
were around 45 ms (Cambridge), 70 ms (San Diego), and
130 ms (United Kingdom). One issue in the experiments on
the PlanetLab was that we could only simulate nine clients
using nine nodes. It is because we couldn’t use IP aliasing
on these nodes without root privileges. To make the
experiment environment more realistic, we ran SURGE on
other machines to simulate another 100 clients to access the
service at the same time.
WEI AND XU: MEASURING CLIENT-PERCEIVED PAGEVIEW RESPONSE TIME OF INTERNET SERVICES
TABLE 1
The Summary of Experiment Results
The page split and page merge are two types of false page delimitations.
To further evaluate sMonitor’s accuracy in different
operating conditions, we implemented a network simulator
similar to [29] and Dummynet [27] to simulate wide-area
network conditions. In these experiments, two machines
were used as clients and one as network simulator. They had
the same hardware configurations as the server and were
connected by a 100 Mbps Ethernet. We changed the network
routing in the server and client machines so that the packets
between them were sent to the simulator. Upon receiving a
packet, the simulator routed the packet to an “ethertap”
device. A small user-space program read the packet from the
“ethertap” device, delayed or dropped it according to the
settings, and wrote it back to the device. The packet was then
routed to the Ethernet. The simulator was shown to be
effective in simulating wide-area network delays and packet
losses. For example, with the RTT set as 180 ms, ping times
were showing a round trip of around 182 ms.
For the experiments on the controlled environments, we
set the RTT between clients and the server to be 40, 80, or
180 ms. They represent the transmission latency within the
continental US, the latency between the east and west coasts
of US, and the one between US and Europe, respectively
[28]. Similar to [21], we set the packet-loss rate to 2 percent.
The number of UEs was set to 100. Each experiment lasted
20 min. Because the results showed no clear trend of change
over the increase or decrease of the time window size, we
assumed that the results should be robust in this regard.
5 EXPERIMENTAL RESULTS
5.1 Measurement Accuracy on Average
We conducted comprehensive evaluations under different
network and traffic conditions and compared sMonitor’s
measurements with those obtained by the enhanced SURGE
running on the client machines. We changed the settings in
SURGE to mimic different browser behaviors. We varied the
percentage of requests for container objects that have large
Accept headers. Although the market share of IE and
Firefox is around 93 percent [18], we set the lower bound to
80 percent to investigate the accuracy of sMonitor in
779
environments where nonnegligible portion of clients uses
browsers with different implementations of the Accept
header. For example, in Safari, all requests have the same
Accept headers. We also changed the percentage of
parallel downloaded pages. While we varied this percen-
tage between zero and 15 percent, in this section, we shall
also investigate its effect on sMonitor’s accuracy. In
addition, we varied the percentage of pipelined HTTP
requests. It is to simulate environments where some users of
Firefox may change the HTTP pipelining option from the
default off to on. We shall also examine its effect on the
accuracy of sMonitor, in this section.
Table 1 summarizes the experimental results. Experiments
B and F were conducted on the PlanetLab and others were on
the controlled networks. Because the results on the controlled
networks with different RTTs were similar, in Table 1 we only
present the experiments with the RTT as 180 ms for
simplicity. In all test cases, we observed measurement errors
no larger than 6.7 percent, and the absolute measurement
errors were always smaller than 210 ms. When large Accept
headers were not used in all requests for container objects, the
sMonitor measured response times were always larger than
the client-perceived ones. This is because sMonitor is unable
to perfectly delimit the beginning and end of every page
retrieval because of the lack of size difference between
requests for container and embedded objects. In some cases,
several pages might be falsely identified as one page,
resulting in an estimate of larger response time. On the other
hand, the sMonitor measurements could become smaller
than client-perceived ones when the effects of parallel
downloading and HTTP pipelining become dominant, as
we shall discuss in Section 5.3.
Note that in Table 1, we evaluate the accuracy of sMonitor
via the measurement errors averaged over all retrieved pages
in the 20-min experiments. We also investigated the transient
behaviors of sMonitor. Fig. 6 shows the average response
times measured by sMonitor in experiment A in different
time scales, and compares them with those measured from
the client sides. For brevity, we only present the results in the
period from 200th to 400th second.
780 IEEE TRANSACTIONS ON PARALLEL AND DISTRIBUTED SYSTEMS,
Fig. 6. Comparisons of average response times for experiment A. (a) Average for every 5 s. (b) Average for every 1 s.
The results show that most measurement errors are less
than 2 s for the 1-s interval results. It further indicates that
sMonitor is accurate in measuring client-perceived response
times. Comparing the 1-s and 5-s interval results, we can
observe that the 5-s interval results have smaller errors
(0.473 s) than the 1-s interval results (1.136 s). This is
because the large average interval can decrease the effect of
the measurement lag on the accuracy of sMonitor. Such a
result also demonstrates that it is necessary to include the
measurement lag in assessing the accuracy of sMonitor.
5.2 Measurement Accuracy of Individual Pages
We further investigated the accuracy of sMonitor by
comparing its measured response times of individual pages
against those measured from the client sides. Fig. 7 presents
the scatter plots, which we used to determine relationships
between two measurements. Fig. 7a shows the comparison
results for the experiments conducted using live secured
Internet services. In Fig. 7b, we present the measurement
comparisons of experiment B for requests sent by SURGE
running on the nodes on the PlanetLab. Fig. 7c shows the
comparison results of experiment A. From these figures, we
can observe that there is a strong linear relationship
between these two measurements. Such a linear relation-
ship indicates that sMonitor measured response times are
very close to those measured from the client sides. Actually,
the stronger the linear relationship between the measure-
ments, the more accurate sMonitor is. This is also confirmed
by Fig. 7d, which presents the error distributions of
Fig. 7. Response time comparisons for individual pages. (a) Live secured Internet services. (b) On the PlanetLab. (c) On the controlled
environments. (d) Error distributions.
VOL. 22, NO. 5, MAY 2011
individual pages for experiments conducted on PlanetLab
and controlled testbed. From Fig. 7d, we can observe that
the measurement errors for most individual pages are close
to zero.
Furthermore, the correlation coefficient of the results
from the PlanetLab and the controlled networks is 0.96 and
0.98, respectively. Notice that the closer the correlation
coefficient to 1 (a perfect monitoring where every page is
measured accurately), the more accurate sMonitor is. These
results demonstrate that sMonitor can accurately measure
client-perceived response times in different environments.
Notice that the measured response time of one client is
not affected by those of other clients. This is because
sMonitor measures response time of a client separately by
delimiting its own page requests. Moreover, from Fig. 2 we
can observe that, the changes of network characteristics
during one page retrieval does not affect the accuracy of
sMonitor significantly as long as the requests for container
objects are identified correctly. For example, assume that
the packet loss rate changes during retrieval of a page and it
causes the request for embedded object i to be retransmitted
several times. sMonitor treats these retransmissions as
requests for different embedded objects rather than the
same object. The accuracy of measured client-perceived-
response time is, however, not affected.
5.3 Measurement Accuracy in Various Browser
Settings
To further investigate the accuracy of sMonitor in
different operating environments, we conducted three
WEI AND XU: MEASURING CLIENT-PERCEIVED PAGEVIEW RESPONSE TIME OF INTERNET SERVICES
Fig. 8. Accuracy of sMonitor in different operating environments.
sets of experiments with different settings of usages of
large Accept headers, parallel downloading, and HTTP
pipelining. Each set consists of 21 experiments. Fig. 8
plots the results.
Fig. 8 shows that, with the increasing usage of large
Accept headers, sMonitor’s measurement error decreases.
For example, when no large Accept headers are used in
requests for container objects, the average response time
measured by sMonitor is 4.269 s while the actual client-
perceived response time is 3.185 s. The measurement error
is 34 percent. In this case, sMonitor solely relies on the
timeout mechanism to delimit webpages. It identifies all
requests issued within the timeout period as requests for
one single page although they may be for different pages.
Thus, sMonitor measures larger response times than those
measured from the client sides. The usage of large Accept
headers helps sMonitor to delimit pages even when the
requests are issued within the timeout period and to reduce
the measurement errors. Notice that in this set of experi-
ments, we set the usage percentages of both parallel
downloading and HTTP pipelining to zero to prevent them
from affecting our accuracy evaluation of sMonitor.
Fig. 8 also shows the accuracy of sMonitor in environ-
ments with different percentages of parallel downloaded
pages. In this set of experiments, the large Accept header
ratio was set to 100 percent and no HTTP requests were
pipelined. From this figure we can gain two insights. First,
the sMonitor measured response times are smaller than
those perceived by clients. In our experiments, when
several pages are parallel downloaded, two TCP connec-
tions are established for each page. This is to mimic the
behavior that a new IE is executed. From the viewpoint of a
client, parallel downloading does not reduce the response
times of individual pages. For sMonitor, however, the total
downloading time of these pages becomes smaller because
their requests are overlapped.
Second, with the increasing usage of parallel down-
loading, more requests are overlapped and sMonitor
measures smaller response times. For example, when only
10 percent webpages are parallel downloaded, the average
response time measured by sMonitor is 3.085 s and the
measurement error is 1:4 percent. When all webpages are
parallel downloaded, while the measured response times
from the client sides are similar, the measured average
response time from sMonitor is reduced to 2.794 s. It is
equivalent to a measurement error of about 10 percent.
HTTP pipelining is another factor that we need to
investigate for the evaluation of the accuracy of sMonitor. In
the experiments, we assumed that all requests for container
781
objects had large Accept headers and no pages were
parallel downloaded. Fig. 8 also plots the results. They
show that, the more pipelined requests, the larger the
measurement error. For clients, pipelining of HTTP requests
can reduce their perceived response times since several
requests for embedded objects are sent to the server within
one packet without waiting for each response. On the other
hand, size differences between pipelined requests for
embedded objects and those for container objects become
smaller. This may cause sMonitor to delimit multiple pages
as one only. As a result, with the increasing usage of
pipelined requests, sMonitor measures larger response
times than those client-perceived.
5.4 Accuracy of Page Delimitation
sMonitor’s accuracy on response times is mainly determined
by its accuracy on page delimitations. There are two types of
false page delimitations. The first type is page split that one
page is identified as multiple pages. The second type is page
merge, in which multiple pages are identified as one.
In Table 1, we also present the results of these two
types of false page delimitations in different environments.
For example, in experiment A, the total percentage of
falsely delimited pages was as low as 3 percent. With these
falsely delimited pages, the measurement error was only
0.3 percent. In all experiments, split pages were less than
2.3 percent and merged pages were less than 17 percent.
They further demonstrate the high accuracy of sMonitor in
measuring client-perceived response times.
To investigate the causes of false page delimitations in
sMonitor, we conducted experiments with different set-
tings. Fig. 9 shows the experimental results. In Fig. 9a, we
present the effect of the usage of large Accept headers on
page delimitations. The results show that the usage of large
Accept headers has negligible effect on split pages. This is
because the sizes of requests for embedded objects are not
affected. These requests have similar sizes and sMonitor
does not identify them as the beginnings of pages.
With the increasing usage of large Accept headers,
Fig. 9a also shows that the number of merged pages
significantly drops from 65.3 percent to 2.5 percent. This
demonstrates that large Accept headers are effective for
helping sMonitor to delimit pages.
We also conducted experiments to determine how
sMonitor’s accuracy on page delimitation is affected by
parallel downloading. Fig. 9b plots the experimental results.
From this figure we can observe that, with the increasing
usage of parallel downloading, more pages are split or
merged. This is expected since if two pages are parallel
downloaded, requests for their container and embedded
objects will interleave each other and lead to false page
delimitations. Moreover, since parallel downloading will
not change request sizes, its effect on split and merged
pages is small. For example, when the percentage of parallel
downloaded pages varies from 20 percent to 75 percent, less
than 4.5 percent pages are split and no more than 6.5 percent
are merged.
Given the fact that HTTP pipelining is becoming
popular, we conducted more experiments to determine
how it affects the accuracy of sMonitor. Fig. 9c plots the
experimental results. It is clear that HTTP pipelining has
782 IEEE TRANSACTIONS ON PARALLEL AND DISTRIBUTED SYSTEMS,
Fig. 9. Effect of browser behaviors on sMonitor’s accuracy on page
delimitation. (a) Accept header. (b) Parallel downloading. (c) HTTP
pipelining.
little effect on the number of split pages. On the other hand,
with the increasing usage of HTTP pipelining, the number
of merged pages increases. This is because pipelined
requests for embedded objects make size differences
between requests for container and embedded objects
smaller. sMonitor becomes more likely to merge multiple
webpages into one instead of splitting pages.
In addition to the overall results, we also investigated
detailed behaviors of sMonitor in delimiting pages. Fig. 10
depicts the scatter plots for experiment E. Because split
pages do not exist in client-retrieved pages, in Fig. 10, they
are plotted as points with x value as zero. Similarly, merged
pages are plotted as points with y value as zero.
Fig. 10 shows that there are more delimited pages above
the line than below the line, which consists of accurately
delimited pages. It implies that sMonitor measures larger
response times for the pages above the line than SURGE
Fig. 10. Page delimitations in experiments E.
VOL. 22, NO. 5, MAY 2011
Fig. 11. Cumulative distribution function of the measurement lags in
experiments C and G.
from the client sides. In all other experiments, we have
similar results. This is because there are more merged pages
than split ones, which can be observed from Fig. 9. Because
a merged page actually is a mix of several pages, it has a
larger response time.
5.5 Measurement Lag of sMonitor
Recall that measurement lag refers to the time difference
between the time of the retrieval end of a page and the time
the same page is delimited by sMonitor. To measure the
measurement lag of sMonitor, we synchronized all client
machines and servers with one NTP server. In addition, we
only calculate the lags of those correctly delimited pages to
prevent those falsely delimited ones from affecting our
evaluations.
Table 1 also shows the mean measurement lags in the
last column. They vary between 3.5 and 4 s. More
importantly, they are at least 0.5 s longer than client-
perceived response times on average. This suggests that
requests for a page could be processed within one
measurement lag. Therefore, it is important to take the
measurement lag into account in order to effectively
manage client-perceived response times [19], [33]. That is,
to control response times, a scheduler needs to obtain
current system status promptly in order to determine which
client should be processed next. Due to the measurement
lag, however, a scheduler has to decide processing order of
client requests based on lagged system status, which might
be very different from current system status.
We also examined detailed behaviors of the measure-
ment lag. Fig. 11 plots the cumulative probability distribu-
tions of the measurement lags for experiments C and G.
From Fig. 11, we can see that all pages were delimited
within 5 s after their responses end. This is because of the
timeout setting used in sMonitor. In addition, 14 percent
measurement lags are 5 s. It suggests that these pages
should be delimited via the timeout mechanism. Further-
more, about 75 percent measurement lags are larger than 3 s
and 50 percent are larger than 4 s. They further show the
importance of the measurement lag.
To investigate the measurement lag in different environ-
ments, we conducted three sets of experiments with
different settings of large Accept headers, parallel down-
loading, and HTTP pipelining. Fig. 12 shows the experi-
mental results. With the increasing usage of large Accept
headers, we can clearly see that the measurement lags
become smaller. This is because the usage of large Accept
headers helps sMonitor to identify the beginnings of pages
and to delimit pages more promptly.
WEI AND XU: MEASURING CLIENT-PERCEIVED PAGEVIEW RESPONSE TIME OF INTERNET SERVICES
Fig. 12. Effect of browser behaviors on the measurement lag.
Parallel downloading also helps to reduce the measure-
ment lag significantly. For example, the measurement lag
decreases from 3.899 s without parallel downloading to
2.507 s when as many as possible pages are parallel
downloaded. Such a reduction is due to the decrease of
the interarrival times between requests for pages. When two
pages are sequentially downloaded, the measurement lag is
the time difference between the response end of first page
and the arrival of the request for container object of the
second page.
Meanwhile, HTTP pipelining has little effect on the
measurement lag. For example, when HTTP pipelining was
not used, the average measurement lag was 3.899 s. It drops
to 3.755 s when as many as possible HTTP requests were
pipelined. This decrease is expected because pipelining of
HTTP requests provides no help in delimiting pages.
To determine the effect of the measurement lag on page
delimitations, we compare the numbers of delimited pages
for each 1-s interval measured by sMonitor and SURGE for
experiment C. Fig. 13 shows the differences between the
results from sMonitor and SURGE measurement in different
timescales. From Fig. 13a, we observe that the average
difference in a 5-s interval is about 1.8 pages or 26 percent
delimitation error. It is in contrast to the result of 2.2 pages or
42 percent delimitation error in the timescale of 1-s interval.
Although all pages are delimited within 5 s of their
response ends as shown in Fig. 11, using 5 s as the average
interval does not eliminate the measurement lag. This can
be observed from Fig. 13a. It is because the end of a page
may be identified in one average interval while the page
ends in previous one. How to further reduce the measure-
ment lag is part of our future work.
6 RELATED WORK
Existing response-time monitors can be classified according
to the type of monitoring (active versus passive) and the
location of the monitor (client side versus server side).
Active client-side monitors such as Keynote service [12] and
WebProphet [16] are deployed at selected client sites and
Fig. 13. Behaviors of the measurement lags inferred from comparisons of page delimitations. (a) Average for every 5 s. (b) Average for every 1 s.
783
issue service requests as scheduled or by emulation.
WebProphet [16] develops models for object download
times and their dependences by simulating the page load
process. Active monitors have difficulty in emulating real
user behaviors using customized browsers. Meanwhile,
they often only measure the response times of a few
selected webpages from a few selected locations. Such
limitations make the results unrepresentative.
Passive client-side monitors can be embedded instru-
mentation codes inside webpages that can be downloaded
from servers or based on browser instrumentation. The
OpenView Transaction Analyzer (OVTA) from HP [10] is an
example of webpage instrumentations. In OVTA, JavaScript
code is downloaded with webpages to record access times
and to report statistics back to the server. One limitation of
this approach is that those non-HTML webpages, such as
PDF files, are difficult to instrument. In addition, since the
JavaScript code is executed after the instrumented HTML
file is retrieved, typically it is unable to measure the
connection establishment time and retrieval time of the
HTML file. To overcome these limitations, IBM has
proposed Client Perceived Response Time (CPRT) [25].
Beside instrumenting webpages, in CPRT, the hyperlinks
pointing to these webpages are also instrumented using a
JavaScript code so that the retrieval time of the HTML file
can be measured. CPRT, however, is unable to measure the
response times of the webpages that are accessed directly.
Such webpages include those accessed by a client through
typing the addresses in a browser, through the favorite
collections, or through search engines.
Browser-instrumentation approaches place a monitor
between a browser and the network socket layer or within
the browser as a plug-in to access response times of
Internet services from the client’s perspective. The repre-
sentatives include Page Detailer from IBM [11]. This type
of approach has the same drawbacks as active client-side
monitors. Therefore, it is generally used for testing and
debugging services.
Client-side monitors have the advantages that they can
provide the most accurate response time of client-perceived
response times. This includes the latency incurred in
domain name system server inquiries and the time
spending in retrieving objects from locations other than
the monitored servers. Their disadvantages are related to
issues in emulating representative user behaviors. In
addition, they are unable to provide a breakdown between
network and server delays and lack drill-down trouble-
shooting capabilities without additional webserver instru-
mentations. These limitations apply to both active and
passive client-side monitors.
Passive server-side monitors normally measure response
times using an instrumented server or analyzing logs or
784 IEEE TRANSACTIONS ON PARALLEL AND DISTRIBUTED SYSTEMS,
traffic in and out of monitored services. Server-instrumenta-
tion approaches track the request arrivals and response
departures on the application level or on the kernel level.
Application-level server instrumentations, such as [1],
provide an easy way to obtain information regarding
Internet service transactions. They, however, do not consider
network delays incurred during TCP connection establish-
ments or kernel waiting times of client requests. In [20], the
authors showed that application-level approaches could
underestimate response times by more than an order of
magnitude. Kernel-level approaches, such as [20], overcome
these limitations. They, however, measure service perfor-
mance at a per connection level. The measured results are
different from what perceived by end users due to wide
usages of parallel and persistent connections.
Traffic-analysis approaches, including [5], [21], decode
packets to the HTTP layer to identify the beginning and the
end of each HTTP transaction. Since passive server-side
monitors have a detailed view of the monitored system,
they provide the most accurate performance characteristics
of servers. Moreover, they observe actual service traffic, and
therefore, provide a measurement of experiences of all real
clients. They can be deployed easily and run without
interfering a server’s operation. Due the unavailability of
HTTP headers, however, none of these approaches can
measure response times for secured Internet services.
Log-analysis approaches, such as [15], estimate the
response time of a page as the serving time of the container
object and the last embedded object. This approach,
however, suffers the same shortcoming as the application-
level server instrumentation since it does not take network
delays into account. Moreover, with dynamically generated
webpages, it is difficult to determine which embedded
object belongs to which container object without the help of
referrer field.
Server-side monitoring methods, including sMonitor
and ksniffer, share the limitation that they are unable to
measure latencies before clients send packets to servers.
They are also limited to measure the latencies of requests
handled by intermediate components between clients and
servers, such as browser caches and proxies.
Other work on network traffic analysis include the
passive packet monitor used on the AT&T network [6] and
inferring HTTP characteristics from TCP/IP packet headers
[30]. They have discussed many challenges, such as TCP
connection reconstructions, which we faced in the design
and implementation of sMonitor.
7 CONCLUSIONS
We have designed, implemented, and evaluated sMonitor,
a monitor that can determine client-perceived pageview
response times for secured Internet services without
decrypting HTTPS messages. Since sMonitor passively
collects network traffic in and out of the monitored services,
it requires no changes to any part of the services or clients
and can be deployed easily. It measures the response times
nonintrusively using the novel size-based analysis method
on HTTP requests to characterize client accesses and delimit
different pages from live network traffic.
VOL. 22, NO. 5, MAY 2011
We have implemented sMonitor as a stand-alone
application in the user space. We have conducted compre-
hensive evaluations of its accuracy using live Internet
services, on the PlanetLab, and on the controlled networks.
Our results demonstrate the unique ability of sMonitor to
infer client-perceived pageview response times accurately.
More importantly, the measurement is obtained in the
presence of complicated browser behaviors, such as parallel
downloading and HTTP pipelining, as well as packet losses
and delays.
We note that sMonitor is required to be deployed in front of
a website so as to capture all the traffic in and out of the
website. However, in many applications, the objects of a web
page may be located or generated in geographically dis-
tributed websites. How to measure the client-perceived
pageview response time for such web pages deserve further
studies. Recent studies, such as Link Gradients [4] and WISE
[32], made a step forward by developing ways to estimate the
end-to-end request/response transaction time of distributed
applications due to the change of network conditions. On the
client side, there may be a firewall, NAT-enabled router, or
proxy in general that hides clients from server by changing the
request sources to the proxy. In this case, sMonitor would
measure the response time to the proxy, instead. sMonitor
treats the requests from different clients as parallel down-
loading and the results remain instructional for performance
diagnosis and QoS provisioning.
ACKNOWLEDGMENTS
The authors would like to thank the anonymous reviewers for
their constructive comments and suggestions. This research
was supported in part by US National Science Foundation
(NSF) grants DMS-0624849, CNS-0702488, CRI-0708232,
CNS-0914330, and CCF-1016966. The original idea of the
size-based analysis method appeared in [34].
REFERENCES
[1] J. Almeida, M. Dabu, A. Manikutty, and P. Cao, “Providing
Differentiated Levels of Service in Web Content Hosting,” Proc.
ACM SIGMETRICS Workshop Internet Server Performance, pp. 91-
102, June 1998.
[2] P. Barford and M. Crovella, “Generating Representative Web
Workloads for Network and Server Performance Evaluation,”
Proc. ACM SIGMETRICS, pp. 151-160, June 1998.
[3] N. Bhatti, A. Bouch, and A. Kuchinsky, “Integrating User-
Perceived Quality into Web Server Design,” Proc. Ninth Int’l
World Wide Web (WWW) Conf. Computer Networks, pp. 1-16, 2000.
[4] S. Chen, K. Joshi, M. Hiltunen, W. Sanders, and R. Schlichting,
“Link Gradients: Predicting the Impact of Network Latency on
Multi-Tier Applications,” Proc. IEEE INFOCOM, 2009.
[5] L. Cherkasova, Y. Fu, W. Tang, and A. Vahdat, “Measuring and
Characterizing End-to-End Internet Service Performance,” ACM
Trans. Internet Technology, vol. 3, no. 4, pp. 347-391, 2003.
[6] A. Feldmann, “BLT: Bi-Layer Tracing of HTTP and TCP/IP,” Proc.
Ninth Int’l World Wide Web (WWW) Conf. Computer Networks,
pp. 321-335, 2000.
[7] N. Ferguson and B. Schneier, Practical Cryptography. John Wiley &
Sons, 2003.
[8] R.T. Fielding, J. Gettys, J.C. Mogul, H.F. Nielsen, L. Masinter, P.J.
Leach, and T. Berners-Lee, Hypertext Transfer Protocol - HTTP/1.1.
Network Working Group, Request for Comments 2616bis, June
1999.
[9] F. Hernandez-Campos, K. Jeffay, and F.D. Smith, “Tracking the
Evolution of Web Traffic: 1995-2003,” Proc. 11th IEEE Int’l Symp.
Modeling, Analysis, and Simulation of Computer and Telecomm.
Systems (MASCOTS), pp. 16-25, 2003.
WEI AND XU: MEASURING CLIENT-PERCEIVED PAGEVIEW RESPONSE TIME OF INTERNET SERVICES
[10] HP, “Openview Transaction Analyzer,” http://openview.hp.
com/, 2010.
[11] IBM, “Page Detailer,” http://www.alphaworks.ibm.com/tech/
pagedetailer, 2010.
[12] Keynote Systems, Inc., www.keynote.com, 2010.
[13] R. Kohavi, R. Henne, and D. Sommerfield, “Practical Guide to
Controlled Experiments on the Web: Listen to Your Customers
Not the HiPPO,” Proc. ACM SIGKDD, 2007.
[14] H. Krawczyk, M. Bellare, and R. Canetti, HMAC: Keyed-Hashing for
Message Authentication. Network Working Group, Request for
Comments 2104, Feb. 1997.
[15] B. Krishnamurthy and C.E. Wills, “Improving Web Performance
by Client Characterization Driven Server Adaptation,” Proc. 11th
Int’l Conf. World Wide Web, 2002.
[16] Z. Li, M. Zhang, Z. Zhu, Y. Chen, A. Greenberg, and Y.-M. Wang,
“WebProphet: Automating Performance Prediction for Web
Services,” Proc. Seventh USENIX Symp. Networked Systems Design
and Implementation (NSDI), 2010.
[17] Microsoft Corporation, “How to Restrict the Use of Certain
Cryptographic Algorithms and Protocols in Schannel.dll,” http://
support.microsoft.com/?kbid=245030, Dec. 2004.
[18] NetApplications.com, “Browser Version Market Share,” http://
marketshare.hitslink.com/report.aspx?qprid=6, Dec. 2006.
[19] D. Olshefski and J. Nieh, “Understanding the Management of
Client Perceived Response Time,” Proc. ACM SIGMETRICS,
pp. 240-251, 2006.
[20] D. Olshefski, J. Nieh, and D. Agrawal, “Using Certes to Infer
Client Response Time at the Web Server,” ACM Trans. Computer
Sysmtems, vol. 22, no. 1, pp. 49-93, 2004.
[21] D.P. Olshefski, J. Nieh, and E. Nahum, “ksniffer: Determining the
Remote Client Perceived Response Time from Live Packet
Streams,” Proc. Sixth USENIX Symp. Operating Systems Design
and Implementation (OSDI), pp. 333-346, 2004.
[22] V.N. Padmanabhan and L. Qiu, “The Content and Access
Dynamics of a Busy Web Site: Findings and Implications,” Proc.
ACM SIGCOMM, pp. 111-123, 2000.
[23] D. Patterson, “A Simple Way to Estimate the Cost of Downtime,”
Proc. 16th USENIX Large Installation System Administration Conf.
(LISA), pp. 185-188, 2002.
[24] V. Paxson and M. Allman, Computing TCP’s Retransmission Timer.
Network Working Group, Request for Comments 2988, Nov. 2000.
[25] R. Rajamony and M. Elnozahy, “Measuring Client-Perceived
Response Time on the WWW,” Proc. Third Conf. USENIX Symp.
Internet Technologies and Systems (USITS), 2001.
[26] Jupiter Research, “Retail Web Site Performance: Consumer
Reaction to a Poor Online Shopping Experience,”technical report,
JupiterKagan, Inc., 2006.
[27] L. Rizzo, “Dummynet: A Simple Approach to the Evaluation of
Network Protocols,” ACM SIGCOMM Computer Comm. Rev.,
vol. 27, no. 1, pp. 31-41, 1997.
[28] S. Shakkottai, R. Srikant, N. Brownlee, A. Broido, and K. Claffy,
“The RTT Distribution of TCP Flows in the Internet and Its Impact
on TCP-Based Flow Control,” technical report, The Cooperative
Assoc. for Internet Data Analysis (CAIDA), 2004.
[29] J. Slottow, A. Shahriari, M. Stein, X. Chen, C. Thomas, and P.B.
Ender, “Instrumenting and Tuning Dataview—A Networked
Application for Navigating through Large Scientific Datasets,”
Software: Practice and Experience, vol. 32, no. 2, pp. 165-190, Feb.
2002.
[30] F.D. Smith, F. Hernandez-Campos, K. Jeffay, and D. Ott, “What
TCP/IP Protocol Headers Can Tell Us About the Web,” Proc. ACM
SIGMETRICS, pp. 245-256, 2001.
[31] Q. Sun, D.R. Simon, Y.-M. Wang, W. Russell, V.N. Padmanabhan,
and L. Qiu, “Statistical Identification of Encrypted Web Browsing
Traffic,” Proc. IEEE Symp. Security and Privacy, pp. 19-30, May
2002.
[32] M. Tariq, K. Bhandankar, V. Valancius, A. Zeitoun, N. Feamster,
and M. Ammar, “Answering “What-If” Deployment and Config-
uration Questions with WISE: Techniques and Deployment
Experience,” Proc. ACM SIGCOMM, 2008.
[33] J. Wei and C. Xu, “eQoS: Provisioning of Client-Perceived End-to-
End QoS Guarantees in Web Servers,” IEEE Trans. Computers,
vol. 55, no. 12, pp. 1543-1556, Dec. 2006.
[34] J. Wei and C.-Z. Xu, “sMonitor: A Non-Intrusive Client-Perceived
End-to-End Performance Monitor of Secured Internet Services,”
Proc. USENIX Ann. Technical Conf., June 2006.
785
[35] J. Wei, X. Zhou, and C.-Z. Xu, “Robust Processing Rate Allocation
for Proportional Slowdown Differentiation on Internet Servers,”
IEEE Trans. Computers, vol. 54, no. 8, pp. 964-977, Aug. 2005.
[36] C.-Z. Xu, J. Wei, and F. Liu, “Model Predictive Feedback Control
for QoS Assurance in Web Servers,” Computer, vol. 41, no. 3,
pp. 66-72, Mar. 2008.
Jianbin Wei received the BS degree in compu-
ter science from the Huazhong University of
Science and Technology, China, in 1997. He
received the MS and PhD degrees in computer
engineering from Wayne State University in
2003 and 2006, respectively. His research
interests are in distributed and Internet comput-
ing systems. He is currently with Yahoo, working
on platforms of cloud computing. He is a
member of the IEEE Computer Society.
Cheng-Zhong Xu received the BS and MS
degrees from Nanjing University in 1986 and
1989, respectively, and the PhD degree in
computer science from the University of Hong
Kong in 1993. He is currently a professor in the
Department of Electrical and Computer Engi-
neering at Wayne State University, the Director
of the Cloud and Internet Computing Laboratory,
and the Director of Sun Microsystems’ Center of
Excellence in Open Source Computing and
Applications. His research interest is mainly in scalable distributed and
parallel systems and wireless embedded computing devices, with an
emphasis on resource and system management for performance,
availability, reliability, energy efficiency, and security. He has published
more than 160 articles in peer-reviewed journals and conferences in
these areas, including more than 20 papers in IEEE and ACM
transactions. He is the author of book Scalable and Secure Internet
Services and Architecture (Chapman & Hall/CRC Press, 2005) and a
coauthor of book Load Balancing in Parallel Computers: Theory and
Practice (Kluwer Academic/Springer Verlag, 1997). He serves on the
editorial boards of IEEE Transactions on Parallel and Distributed
Systems, Journal of Parallel and Distributed Computing, Journal of
Parallel, Emergent, and Distributed Systems, Journal of Computers and
Applications, Journal of High Performance Computing and Networking,
and ZTE Communications. He served dozens of international confer-
ences and workshops in the capacity of program chair, general chair,
and plenary speaker. He was a recipient of the Faculty Research Award,
the President’s Award for Excellence in Teaching, and the Career
Development Chair Award of Wayne State University, and the “Out-
standing Oversea Scholar” award of the National Science Foundation of
China. He is a senior member of the IEEE. For more information, please
visit http://www.ece.eng.wayne.edu/~czxu.
. For more information on this or any other computing topic,
please visit our Digital Library at www.computer.org/publications/dlib.