Characterization of User and
Server Behavior in Web-based
Networks
Amy Csizmar Dalal
Computer Communications Laboratory, Northwestern University
http://www.ece.nwu.edu/~amy
email: [email protected]
Motivation
The Internet is growing rapidly, in terms of users and hosts.
(number of users in millions)
Source: Network Wizards (http://www.nw.com)
Source: Nua Internet Surveys (http://www.nua.ie/surveys)
Congestion occurs at the network level and at the web server. Our focus is on
alleviating congestion at the web server.
Web server operation
USER
NETWORK
Request a file from web
document (*.html, *.gif,
etc.)
WEB SERVER
Find existing thread/process corresponding to the user’s
connection, or start new one.
Parse HTTP request, extracting file name and path of requested
file.
Find and retrieve requested file, or return error message.
Parse response and display in
web browser.
Repeat until all files in web document
have been retrieved.
Add HTTP header and send response to user.
Problems with current web server operation
• Currently, web servers share processor resources
among several requests simultaneously.
• Web users are impatient--they tend to abort page
requests that do not get a response within several
seconds.
• If users time out, the server wastes resources on
requests that never complete--a problem
especially for heavily-loaded web servers.
Objectives
• Service ordering analysis: decrease userperceived latency by minimizing the
number of user file requests that “time out”
before completion
• Server dimensioning analysis: determine
the optimal operating point of a web server,
in terms of performance gains vs. resource
costs
A dynamic-programming model for measuring
web server performance:
• Performance is defined as how much a user would be willing to pay for
service received
• Performance decreases as response time (time a request spends at the
server) increases
• Service times are independent and identically distributed exponential
random variables with parameter 
• Request arrivals are Poisson with rate 
• Incoming requests remain at the server until they complete service
• Server alternates between busy cycles, when there is at least one request
in the system, and idle cycles (state 0), when there are no requests waiting
or in service. These cycles are i.i.d.
• Switching time between requests is negligible
• Consider processor-sharing and non-processor-sharing policies that allow
preemption
Web server performance model (continued)
• Revenue server earns from serving request i to completion under a
service policy p is defined as
gi p (ti p )  e
 c ( ti p  xi )
where xi is the arrival time of request i, c is the revenue decay rate, and ti
p
is the departure time of job i under policy p
• Potential revenue for request i under policy p at time t: g i p (t ), xi  t  ti p
• E [Z1]= expected length of one busy/idle cycle; N=number served in a
busy cycle
• By the Renewal Reward Theorem, the average reward earned by the
server per unit time under a policy p is
N

E  g i p (ti p )


V p ( 0)   i  0
E[ Z1 ]
• The optimal service policy maximizes revenue per unit time:
V  max Vp (0)
p
An optimal service policy from this policy space is...
• Non-idling
• Piecewise-constant: the server only changes the request in service upon
an arrival to or departure from the system
• Non-processor-sharing
• Markov: makes its service decisions independent of past behavior and
future arrivals
• Greedy: chooses to serve the request with the current maximum
potential revenue  p : max g i (t )
i
 Optimal policy is last-in, first-out,
preemptive-resume (LIFO-PR)
Simulation results: total revenue vs. load
Service policies:
Red = LIFO-PR
Blue = First-in, First-out
Green = Processor Sharing
Current research questions:
• How does the optimal policy change if we consider several “classes”
of jobs; i.e., jobs that have service times drawn from distributions that
are not identically distributed?
• How does the optimal policy change if we consider different revenue
functions? (decreasing but non-exponential, exponential with varying
decay constant, etc.)
• Use load analysis and performance measures identified from the
optimal service polices to determine the capacity of a web server.
• Determine optimal operating point of a web server (tradeoff of
resource costs and revenue gains) via queueing model.