JOURNAL OF COMPUTING, VOLUME 3, ISSUE 2, FEBRUARY 2011, ISSN 2151-9617

HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG 1

ALBL, ALBL/HSC algorithms: Towards more

scalable, more adaptive and fully utilized
balancing systems
Sotirios Kontogiannis, Stavros Valsamidis, and Alexandros Karakos

Abstract—This paper presents the performance characteristics of a non-content aware load balancing algorithm, ALBL, for
cluster-based web systems. Based on ALBL potential a new content aware load balancing algorithm is also introduced; called
ALBL/HSC. This algorithm maintains classes of HTTP traffic based on content of HTTP requests.Then it uses ALBL algorithm to
load balance requests per class accordingly. That is, ALBL/HSC maintains separate ALBL processes per HTTP service class
for balancing traffic among web servers assigned to each class.

Performance and scalability gains are shown from tests of ALBL against known balancing algorithms used by web-farms, such
as: Round Robin, Least Connections and Least Loaded. Then, ALBL/HSC algorithm is put to the test against ALBL over a
cluster based load balancing system. Moreover, CPU performance tests performed at the web switch and performance tests at
the web servers indicate both positive features and drawbacks of content aware ALBL/HSC and adaptive content blind ALBL.
This paper also presents new features that can be installed to content aware algorithms. That is, clustering prediction,
bandwidth and web farm utilization estimation and sharing mechanisms among classes of HTTP traffic.

Index Terms—Distributed web systems, load balancing, load balancing algorithms, web clusters.

——————————  ——————————

1 INTRODUCTION

T he growth of web based applications and adoption of

services over HTTP, leads to the building of more
efficient web servers and implementation of different
scheduling policies at requests. The emerging web 2.0
technologies and tools, followed by Google development
toolkit, api's and many social (facebook, twitter), e-health,
e-learning (Learning Management Systems) and e-
government (electronic elections, citizen services) web
services, are mature indications that the WWW and in
turn HTTP is definitely becoming the most excessive form
of traffic for routers, that shall geometrically increase web
server processing efforts over the following years.
Focusing on augmentation of web server performance,
distributed web architectures consisting of web server
farms were introduced as a unified structure and load
balancing architectures were deployed. Such distributed
web architectures are classified to: 1. Distributed web
systems, where a number of web servers that sustain dif-
ferent types of web content or services, interact with cli-
ents. 2. Virtual or Geographically located web clusters,
————————————————
• S. Kontogiannis is with the Electical and Computer Eng. Department,
Democritus University of Thrace, University Campus Kimeria, Xanthi,
67100, Greece.
• S. Valsamidis. is with the Electical and Computer Eng. Department, De- appropriate target servers [1, 2].
mocritus University of Thrace,University Campus Kimeria, Xanthi, 67100,
Greece.
• A. Karakos is with the Electical and Computer Eng. Department, Democri- into content aware (layer 7) and non-content aware (layer
tus University of Thrace, University Campus Kimeria, Xanthi, 67100,
Greece.
where a number of web servers exchange periodically a
virtual IP address that the clients use to connect to, or
service in a static manner, different types of clients based
on IP address geographical location and 3. Cluster-based
web systems (or web clusters), where a centralized point
of connection exists, for serving incoming HTTP requests;
called web switch [1]. In this paper we focus on cluster-
based web systems. This does not mean that the algo-
rithms that are presented in this paper can't be used by
other distributing architectures. A short analysis of clus-
ter based web systems follows.
A cluster-based web system is comprised of a farm of
web servers joined together as a single unity. These serv-
ers are interconnected and oppose a single system image.
A cluster-based web system is advertised with a single
site name and a virtual IP address (VIP). The front end
node of a cluster-based web system is the web switch. The
web switch receives all in-bound connections that clients
send to the VIP address and routes them to the web
server nodes. A cluster-based web system design is com-
prised of two basic components; the balancing process, that
selects the best suited target servers to respond to re-
quests and the routing mechanism, that redirects clients to
Cluster-based systems routing mechanisms are divided
4). Analysis of layer 7 and layer 4 routing mechanisms
follows.
JOURNAL OF COMPUTING, VOLUME 3, ISSUE 2, FEBRUARY 2011, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG
Balancing systems that use layer 7 routing are mainly
proxy servers or application gateway systems [3, 4, 5].
Such systems redirect requests at application layer caus-
ing requests to traverse the entire protocol stack and thus
limit their performance potential as number of requests
increase. Usually such systems try to moderate degrada-
tion of cluster performance by limiting the number of
users that request service, or with the use of caching tech-
niques at the web switch. Other implementations of layer
7 routing use kernel space request dispatching techniques
instead of user space request dispatching at the web
switch. Kernel dispatching mechanisms are: TCP splicing
[6, 7, 8], TCP handoff [9], TCP binding [10] and TCP re-
building, a TCP connection transfer mechanism [11]. In
conclusion, there is still lack of content management
mechanisms that shall enable efficient content request
routing.
Layer 4 routing mechanisms redirect connections
based on less sophisticated balancing algorithms, which
are unaware of session or application layer attributes.
Routing mechanisms used in a non content aware web
switch are the following: Distributed packet rewriting
(Direct Routing) [14], IP network address translation,
Packet tunnelling and Link layer packet forwarding (also
referred to as MAC address translation) [15, 2].
2 L OAD BALANCING ALGORITHMS FOR CLUSTER
BASED SYSTEMS
We categorize load balancing algorithms used at a web
switch into five distinct categories: 1. Stateless non-
adaptive, 2. stateful non-adaptive, 3. stateless adaptive, 4.
stateful adaptive and 5. content aware. As stateful/stateless
algorithms, we characterize those algorithms that keep
track or not of client connection requests. As adaptive/non-
adaptive, we characterize those algorithms that take into
account web server status metrics feedback and adapt
their behaviour based on metric transitions accordingly,
while content aware algorithms extend adaptive algorithm
potential by also investigating HTTP request header in-
formation and HTTP request payload size (content
length) for balancing decisions.
Stateless non-adaptive algorithms do not consider any
kind of system state information. Typical examples of
such algorithms are Random and Round Robin. Both
Random and Round Robin policies can be easily extent to
treat web servers of heterogeneous capacities that remain
constant through time [15, 2, 1]. In addition, Weighted
Round Robin (WRR) can be used as a stateless balancing
algorithm on web servers with different but known proc-
essing capacities.
Stateful non-adaptive algorithms keep track of client
connections at the web switch. Main representatives of
this category are Least Connections, Weighted Least
Connections (LC-WLC) algorithms [16, 17]. Moreover,
2
Shortest Expected Delay (SED) and Never Queue sched-
uling algorithms use similar approach to LC algorithm
and assign client connections to the web server with the
shortest expected delay [18].
Stateless adaptive balancing algorithms take into ac-
count web server state metrics but do not keep track of
connection state information. These algorithms use moni-
tor agents running on either the web switch or web serv-
ers. The information retrieved from agent lookups is
taken into account in order to determine balancing
weights. Some commonly used metrics are: CPU load,
memory usage, disk usage, current process number and
ICMP request-reply time. An example policy algorithm
called CLBVM (Central Load Balancing for Virtual Ma-
chines) is presented at [19]. In some other cases, web
server metric values are stored by SNMP agents at the
web servers and retrieved by the web switch SNMP man-
ager [20]. Another load balancing algorithm-protocol is
the Openflow protocol that utilizes OpenFlow capable
switches and NOX controllers. Openflow uses a new al-
gorithm called LOBUS (LOad Balancing over UnStruc-
tured networks), presented at [21], that keeps track of sta-
tistic information from Openflow capable switches in or-
der to allocate and commit network resources for each
web server in an unstructured web balancing network.
Adaptive algorithms weight calculation formulas are
based on augmentation of web server metric values fol-
lowed by normalization process. That is, a linear aggre-
gate in terms of summation of metric values load value
as: Agg
n
= ∑ Ki ⋅ SM ik ,where: Agg load i , is
load i
i =1 Wi = W0 + 1 − n
∑
=1
Agg load i
i
the aggregate load calculated weight per web server and
SM ik are the web server metrics used [2, 1, 16]. Moreover,
also non linear weight calculation processes may be ap-
plicable, such as the following formula used by Linux
load balancer to calculate web server
weights: W = W0 [22, 23, 17].
1 − Aggload i
i
3
System components that offer load predictions based
on system (web server) resource metrics are called load
trackers and systems that try to predict web servers be-
haviour based on load tracker results are called load pre-
dictors. Usually, both trackers and predictors do not op-
erate on the same system due to performance issues. Load
trackers are divided into: 1. Linear, such as simple mov-
ing average trackers, as previously mentioned formu-
∑j M j
las: SMA( Sn(ti )) = , or exponential moving aver-
n
age: EMA( Sn (ti )) = a ⋅ Sn + (1 − a ) ⋅ EMA( Sn (ti −1 )) , or simple
moving median (SMA). Autoregressive models (AR) are
also considered linear tracker functions, since they use
JOURNAL OF COMPUTING, VOLUME 2, ISSUE 8, AUGUST 2010, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG
linear functions to calculate weights from metric values.
AR model is a linear combination of the past k resource
metric values represented as a vector. AR load tracker
weight value over time is calculated as:
AR( Sk (ti )) = a1 ⋅ St + ... + a k ⋅ St + e(t ) , where e(t) is a
i i − k −1
distribution sequence of difference or deviation of metric
values, called residuals sequence. In addition, ARIMA
models (Autoregressive Integrated Moving Average) [24,
25] are obtained by the AR model and the moving aver-
age model as a linear combination of the past metric val-
ues and q noise terms of the calculated metric values.
Based on tracked data measurements over a time period,
residual and differential measured data values are calcu-
lated and weight value is predicted. 2. Non-linear load
trackers, such as cubic spline function and two sided
Quartile-Weighted Median (QWM) [24, 25] and previ-
ously mentioned linux local director weight calculation
formula [22], can also be used by web servers for load
prediction and in some cases perform better than linear
trackers do (more responsive to load incidents). Accord-
ing to [25], AR and ARIMA are inadequate to support
run-time decision systems in cases of highly variable
work case scenarios.
Stateful adaptive algorithms use both adaptive algo-
rithm metrics and client flow state information such as:
Number of connections or ratio of connections that a
server has received to the average connections received at
a specific time interval [23, 17], source or destination IP
address (locality aware based [26, 16]). The predictive
probabilistic load balancing algorithm (PPLB) uses adap-
tive weights based on a utility function that follows the
difference and deviation in predicted average and meas-
ured web server response time: F ( S (t ), S ) and the avail-
able processing capacity (remaining utilization capability
Ui of each web server: Wi = (1 − U i (t ) + F (t )) .PPLB algo-
rithm then uses a scheduling policy called Probabilistic
Preferred Short Job (PPSJ) that uses several classes of web
traffic at the web switch. This policy gives precedence to
HTTP requests that belong to a class with relatively
shorter service time and a large number of requests in its
queue waiting for service [27]. Other stateful adaptive
implementations include MALD, which uses agents that
instantiate at the web server, in order to inform the sys-
tem about the web-server's load based on an index that
takes web switch connections per web server into account
[28]. Finally, simulated annealing load balancing algo-
rithm (SA), uses an energy function that scores each one
web server based on the following metrics: request rate,
request processing rate, web server processing capability
and average waiting time of each request in the web
server queue. This algorithm also uses penalty thresholds
and penalty drops [29].
3
Content aware load balancing algorithms are used both
by layer-7 cache clusters and layer-4 web switches. Layer-
7 switching was implemented in the kernel of operating
systems (Linux layer-7 filtering [12, 13]), thus improving
the overall performance of previous layer-7 balancing
algorithms. OS kernel layer 7 filtering capability lead to
the development of new balancing algorithms based on
packet content and routing based on priority service. Bal-
ancing algorithms based on layer-7 filtering analyze
HTTP headers of requests from clients and adopt blind or
cached dispatching policies [30, 31]. Characteristic exam-
ples of content aware dispatching policies follow.
Workload Aware Request Distribution policy (WARD)
[32] assigns the most common HTTP requests to the same
server, while partitioning the rest of the requests to the
same web servers for the same types of requests. More-
over, LARD (Locality Aware Request Distribution) im-
proves cache hit rate in back end server by serving the
same requests to the same servers [33, 34], while Client-
Aware Policy (CAP) tries to reach load balance by provid-
ing multiple classes of service at the web switch [35].
CWARD/CR, CWARD/FR [33] policies also take into ac-
count web server workload and provide content based
prioritized classification for HTTP requests.
The combination of content-aware load balancing and
HTTP service classification was introduced to meet the
demands of complex HTTP requests that combine dy-
namic web pages, database transactions, multimedia and
real-time services. Such mechanisms provide more effi-
cient load balancing for web services not only per flow
but also per service request. LARD/RC, distributes re-
quests based on a requests table incorporated at the web
switch, which assigns requests of the same type to one
cluster of web servers responsible for serving each re-
quest type. It also uses a WLC scheduling policy for the
assignment of requests [36]. GCAP policy group’s re-
quests based on CAP (Content aware request distribution
policies) and then assigns in a WRR fashion requests of
the same CAP class for each web server [36]. Moreover
PPLB algorithm classifies web requests into different
classes based on their service demands for resources at
the web server [27].
3 PROPOSED ALGORITHMS
We designed and implemented a stateful adaptive load
balancing algorithm, called Adopt Load BaLancer (ALBL).
ALBL tries to predict congestive network conditions and
web server load incidents in order to perform its balanc-
ing decisions. Preliminary versions of the algorithm were
presented at [37, 38] We also present a new content aware
load balancing algorithm ALBL/HSC (Adopt Load BaL-
ancer with Hierarchical Service Classes) that maintains a
classification discipline per HTTP service type. Then it
JOURNAL OF COMPUTING, VOLUME 3, ISSUE 2, FEBRUARY 2011, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG
uses ALBL algorithm for balancing HTTP requests per
service class.
3.1 ALBL Algorithm
ALBL algorithm uses agents that probe web servers of a
web server farm periodically. Metric values derived from
this probing process are used for weight calculation and
therefore for balancing decisions at the web switch. We
implemented a cluster based web system that uses Linux
netfiler kernel api [13] for marking and routing client
HTTP requests to a pool of web servers. A Linux kernel
WRR scheduler uses the calculated weights in order to
forward forthcoming requests at the web switch, using
Direct Routing or NAT to the selected web server. Then
the web server responds to the request and communicates
directly to the client (Direct Routing case) or via web-
switch (NAT case). Direct Routing capability was imple-
mented in the latest version of our algorithm, that until
recently supported only NAT routing capabilities (the
whole HTTP flow passed through the web switch). We
also altered the algorithm's behavior towards HTTP flows
that are under service. Such flows are marked as “ser-
viced flows” and are extracted from the forwarding proc-
ess to another web server, if the selected balancing web
server changes.
Two metrics are used by ALBL agents to adjust web
server weights.These metrics are: HTTP response time and
network delay metric. Metric values are periodically up-
dated at a predefined interval period Tp by agents. HTTP
response time metric is calculated as follows: The web
switch sends an HTTP request for a predefined object or
process to each one of the web servers and waits for a
reply. Then calculation of the time that the request was
sent and the time that the web server FINs the request
occurs. The time difference between request and FIN re-
ply is equal to the metric value. HTTP response time met-
ric is equal to the sum of network propagation delay,
network queuing delay and web server processing delay.
That is: HTTPresp = QPr op + Qn + QPr oc , where propaga-
tion delay QPr op follows the assumption that is the equal
for all web servers, queuing delay: Qn is the sum of all
the delays encountered by a packet from the time of its
insertion into the network until the delivery to its destina-
tion and processing delay: QPr oc , is the time needed for a
web server scheduled thread to process a request and
construct an appropriate reply message. Processing delay
depends on web server CPU load index and web service
response capability.
Network delay metric calculation is achieved by a
minimum size TCP SYN packet constructed at the web
switch with source the IP address of the web switch and
destination the IP address of each one of the web servers.
4
Agents responsible for network delay calculate the re-
sponse time between TCP SYN request and SYN|ACK
reply (TCP half connection). This time difference is an
approximation of propagation and queuing delay at the
network path between the web switch and the web
server. Network delay metric is a good approximation of
network delay of a small size packet that traverses the
network path from the web switch to the web server, if
the web server is not overloaded. That is:
Ndelay = QPr op + Qn = RTTi , where RTTi is the round trip
time of SYN-SYN|ACK PDU. An appropriate probing
timeout is set for SYN queuing. The timeout value can be
modified according to network topology and the maxi-
mum expected latency of the system. If timeout occurs
then that web server is removed from the balancing proc-
ess until the next balancing period Tp.
In order to discriminate among web server CPU load
and network congestion incidents, a more of a static
threshold value is used by the algorithm as follows: If at
least one web server has HTTP response time
( HTTPresp ) less than the fixed threshold value, the algo-
i
rithm concludes that this is due to transient web server
load and network congestion incidents are set to be of less
significance. So weight calculation is performed using the
product of HTTP response time ( HTTPresp ) with net-
i
work delay metric ( ndelayi ), as in (1), where ki is a pa-
rameter that depends on the requested object size over
network MSS value. If network delay metric value is
smaller than HTTP response time metric value, (1) does
not provide adequate responsiveness towards network
congestion incidents, but can fairly estimate
web server load status.
1
HTTPrespi ⋅ ndelayi
Wi = n
1
∑
i =1 HTTPresp i − ki ⋅ ndelayi
(1)
If all web servers have HTTP response time metric
value greater than threshold value, then the algorithm
assumes that such bottleneck is mainly caused by net-
work congestion incidents due to burst client requests
followed by persistent load occurrences at the web server.
So a more sensitive approach to RTT variations, a non
linear (exponential) approach is used for weight calcula-
tion (use of (2)).
1
ndelayi2 ⋅ ( HTTPrespi − li ⋅ ndelayi )
Wi = n
1
∑
=1
i ndelay 2
⋅ ( HTTPrespi − li ⋅ ndelayi )
i
(2)
As we can spot from (2), the processing delay metric for
each web server is estimated by the subtraction of li
JOURNAL OF COMPUTING, VOLUME 2, ISSUE 8, AUGUST 2010, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG
times the network delay metric from the HTTP response
time metric, where li is the number of packets transmit-
ted and received by the HTTP response time agent (for
downloading a specific object from the web server). Then
the product of the processing delay metric to the network
delay metric is used for weight calculation. The weight
value derived from (2) increases exponentially propor-
tional to the network delay deviation and can spot con-
gestion incidents, because web server processing time
metric values ( TPr ), are closer to the network delay met-
i knowledgments follow after the PUSH TCP packets at the
ric values than the HTTP response time metric values are
(close to real processing time). That indicates that (2) is
more responsive for conditions where a web server has
less computational load than link network delays or link
network delays forebode persistent load incidents at the
end nodes.
Concluding, (1) does not provide adequate respon-
siveness towards network conditions, but can fairly esti-
mate load conditions. Alternatively, from (2), a processing
delay metric value for each web server request is ex-
tracted from the HTTP response time metric. The product
of the processing delay metric to the square of the net-
work delay metric is more responsive to network delay
variations and can spot congestion incidents. ALBL algo-
rithm smoothness or responsiveness is proportional to the
periodic probing frequency Tp. If Tp ≤ 2 ⋅ Tg (50ms
≤ Tg ≤ 100ms, is web-switch clock granularity), then
web-switch computational effort increases dramatically
while if Tp ≥ 20 ⋅ Tg , then ALBL cannot spot or compen-
sate for short duration congestion or load incidents.
3.2 ALBL/HSC Algorithm
ALBL/HSC algorithm is a content aware extension of the
adaptive ALBL algorithm. This algorithm includes sepa-
rate ALBL algorithm processes into five classes of HTTP
requests of different service type as mentioned in section
3.3. Classes maintained by ALBL/HSC include the follow-
ing: Class 1: static and lightly dynamic HTTP traffic
(Normal HTTP traffic), class 2: NCQ HTTP traffic, class 3:
Max throughput HTTP traffic, class 4: Multimedia traffic
and class 5: SSL traffic. HTTP requests are classified into
each one of the previous classes based on HTTP request
URI extension (for multimedia traffic, normal traffic),
HTTP reply content length (NCQ traffic, max throughput
traffic) and request protocol (SSL traffic). A short analysis
of the classification and discipline methodology used per
HTTP service class follows.
3.3 ALBL/HSC service classes
Web services maintain different characteristics in terms of
bandwidth usage and web server utilization. Web ser-
vices include real-time, interactive, multimedia services,
5
services that require secure communication channels,
video on demand, file transfer services, gaming, confer-
ence broadcast services, informatory services (blogs, fo-
rums, wikis, rings, etc) and other types of service.
HTTP traffic pattern is based on a request-reply
mechanism, where the request is usually a small packet
no more than 512 bytes and the reply is a set of PUSH
packets that its size depends on the web service that is
requested (multimedia data, file transfer, news HTML
report, script that executes either on client or server). Ac-
end of the reply (if the reply is of 2RTO time or at k RTT
time intervals). There is of course the case of burst UDP
packet ACK replies (for multimedia type of traffic). In
conclusion, response time for small size HTTP packets are
constrained by TCP slow start mechanism and large
packets and thus present bigger throughput deviation
(RTT deviation), while large TCP packets are favoured
more by TCP congestion avoidance mechanism and
achieve much more constant throughput (smaller RTT
deviations as packet size increases)[39].
Distinct patterns of web services utilization efforts
(CPU-memory or BW resources), lead to the demand of
web services classification, performed either at the end-
point web server or by the intermediate routers. Web ser-
vices classification attempts are presented in [35, 40, 27,
30] with formalised categories such as web publishing
(static and lightly dynamic services), web transaction
(disk bounded services), web commerce and web multi-
media services. Another web service classification at-
tempt is also presented in [41], as issuance, affair, dy-
namic security and multimedia types of service.
Taking into account the previous web service catego-
ries, we take the assumptions one step further; In order to
preserve and cope with the distinct characteristics of web
services such as real-time interactive and multimedia, to
provide a separate channel for web cryptographic ser-
vices (close to an anonymous channel) and by taking into
consideration the aforementioned studies, ALBL/HSC
disciplines HTTP traffic into the following categories
(service classes):
Normal HTTP Traffic: This type of traffic is provided
either by (a) static or (b) light dynamic content informa-
tion, requested by clients. Discrimination among static
and dynamic content that may consume web server re-
sources are left to web server metrics. Dynamic content
data may over-utilize web server resources more than
static content data, but both categories (a) and (b) present
similar characteristics from the network's point of view,
but not for the web server. Further classification may be
required and is set as a future study.
Non Congestive Real-time traffic: This type of traffic
includes flows that use small packets in terms of size,
whose priority is predetermined by a static NCQ thresh-
JOURNAL OF COMPUTING, VOLUME 3, ISSUE 2, FEBRUARY 2011, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG
old rate [42, 43]. These HTTP flows must experience
minimum network delay and high priority precedence.
From this type of traffic TCP acknowledgments that do
not belong to the aforementioned HTTP flows are ex-
cluded, so as not to drain the NCQ mechanism of instant
service for small packets (NCQ threshold is set to more
than 75 and less than 450Bytes).
Maximum Throughput Traffic: Maximum throughput or
congestive interactive HTTP traffic flows contain packet
sizes near network MTU size and usually such flows op-
erate in bursts. Typical examples of this category of HTTP
traffic are: HTTP download chunks, P2P application traf-
fic over HTTP and huge data size up-link HTTP POSTS.
Congestive Multimedia Traffic: Multimedia Traffic is
HTTP or non-HTTP streaming video and audio traffic,
instantiated by HTTP requests. Non-HTTP multimedia
traffic is mostly carried out by UDP flows or UDP encap-
sulated packets over HTTP. Such kind of traffic must be
taken into consideration as it can degrade web server per-
formance due to its persistent nature.
Secure HTTP Traffic: This type of HTTP traffic is pro-
vided by the SSL-TLS protocol suite by secure web ser-
vices such as web commerce. This type of traffic makes
intensive use of web servers CPU resources. In our case a
separate service class was assigned for SSL traffic in order
to maintain anonymous channel attributes.
3.4 ALBL/HSC algorithm and classification schema
ALBL/HSC discipline of the five distinct service classes is
accomplished with a set of layer-7 filter rules [12] per each
class at the web switch. In addition, for each class a farm
of at least two web servers is used for serving requests, as
depicted at Fig. 1. We implemented ALBL/HSC mecha-
nism into Linux kernel by using Linux kernel layer-7 [13,
12] filter mechanism for the packet filtering and marking
process and Linux traffic control mechanism for the clas-
sification and queuing process [44].
Each packet entering the web switch is marked by a
layer-7 filter and leads to one of the WWW traffic classes
where a queuing discipline is maintained that supports
multiple drop precedence levels. We mark HTTP traffic
following AF (Assured Forwarding) marking schema
used by CISCO routers. Assured Forwarding (AF) pro-
vides forwarding of IP packets in N independent classes.
Within each AF class, an IP packet is assigned one of M
different levels of drop precedence. An IP packet that be-
longs to an AF class i and has drop precedence j is
marked with the AF codepoint AFij , where 1 ≤ i ≤ N
and 1≤ j ≤ M .
Currently, AF supports only four classes (N=4) with
three levels of drop precedence in each class (M=3) for
general use, where AFx1 yields the lower loss probability
and AFx2 and AFx3 yield the higher loss probabilities
6
Fig. 1. ALBL/HSC high level architecture design.
accordingly. Each IP packet enters a specific AFxy class,
based on the IP packet DS (Differentiated Services) field,
or DSCP value (Differentiated Services Code Point). That
is the 6 leftmost bits of the IP ToS field, excluding the two
rightmost bits (LSB) used by the ECN (Explicit Conges-
tion Notification) mechanism (see Table 1).
For each service class we use GRED [45], a generalized
RED [46, 47] queuing discipline that supports multiple
drop priorities (16 virtual queues of independent or pri-
oritized drop probability parameter) as required for As-
sured Forwarding [44, 48]. GRED functionality is similar
to RED queuing discipline where the queuing average
packet value qave sets each queue to non drop, or prob-
abilistic drop state; if qave exceeds min thresshold and full
drop if qave exceeds max thresshold [46]. GRED also offers a
priority mechanism for its 16 virtual queues called GRIO
mechanism that operates similarly to PRIO discipline
mechanism. That is, for VQ1: qave = qaveVQ1 , for
VQ2: qave = qaveVQ1 + qaveVQ 2 and so forth for all 16
queues. ALBL/HSC implementation uses the non GRIO
version of GRED discipline. GRED marks the 4 least sig-
nificant bits of a field called tc_index field that is attached
to the packet sk_buff buffer as it traverses through the web
switch (for each packet entering or leaving the web switch
a buffer space is allocated called sk_buff structure and ini-
tialized to the header and data values of the packet). The
sk_buff structure also includes an additional field for op-
erations required by GRED, DSMARK and INGRESS
queuing disciplines, the tc_index field. Another queuing
discipline called DSMARK is responsible for copying the
DS field from the packet ToS IP header to tc_index value.
ALBL/HSC classification functionality is as follows:
First each packet entering the web switch is marked with
a set of layer-7 rules, using generic AF marking AF1-4
(See Table 1), where AF1 is for multimedia class traffic,
AF2 for NCQ traffic, AF3 for normal HTTP traffic, AF4
for max throughput traffic and EF for SSL traffic. EF class
does not use a RED queue, but a TBF queuing discipline
JOURNAL OF COMPUTING, VOLUME 2, ISSUE 8, AUGUST 2010, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG 7

with specified by the administrator max latency value where i=1..4 (4 service classes), NDPi the Network Delay
and higher priority that the entire GRED discipline. That Product value per class, Thri , Thri current and average
is, the bandwidth delay product of SSL traffic is assured
throughput for each class and Ci the number of active
by provisions made by network administrators. In order
connections sustained currently by each class. b = 2 a , is a
to initialize each one of the remaining four classes, some 3
parameters need to be set by the network administrator coefficient parameter for the CBD metric value calcula-
that correspond to the % expected bandwidth share (% tion. Based on CBD metric value HTTP flows that belong
BW, fraction of the link bandwidth-BW) that each class to class 1-4 may fall into each one of the class probabilistic
utilizes and the maximum desired latency that a flow drop phases according to the following criteria:
may suffer passing through each class. These values need 1. Fall to probabilistic drop of AFx1, if qave is below
to be set by the administrator so that the min thresshold and or exceeds min thresshold and CBD value is less
max thresshold values can be calculated from equations (3) 1
than: 3 ⋅ % BWshare ⋅ BW
⋅ min(latency, ndelay )
and (4) [49, 45, 50]: Ci i

1 2. Fall to probabilistic drop of AFx2, if qave exceeds

0.01 ⋅ % BWshare ⋅ latency ⋅ BW
max thresshold =
avpkt min thresshold CBD value is less
8bit / byte ⋅ 1000ms / sec 2
(3) than: 3 ⋅ % BWshare ⋅ BW
⋅ min(latency, ndelayi )
Ci
1
min thresshold = ⋅ max thresshold 3. Fall to probabilistic drop of AFx3, if qave exceeds
3
(4) TABLE 1
where avpkt, is the average packet length as calculated ASSURED FORWARDING PHB GROUP DSCP VALUES

from HTTP traffic that traverses through the web switch. Group Drop Class/ Drop DSCP
For each one of the 4 classes we have three levels of Class Probability
drop precedence (See Table 1). Initially all incoming con- AF1 1/0.02 0x28
nections for a specific class enter via the first level of drop AF1 2/0.03 0x30
precedence. Then for each class based on ALBL algorithm AF1 3/0.07 0x38
metric values an additional exponential weighted moving AF2 1/0.005 0x48
average (EWMA) is calculated of network delay metric AF2 2/0.01 0x50
values for all web servers belonging to a class using the AF2 3/0.015 0x58
following equation: AF3 1/0.01 0x68
n
1 AF3 2/0.15 0x70
NDP = a ⋅ max(ndelayi ) + (1 − a ) ⋅
n
∑
=1
i
ndelayi
AF3 3/0.02 0x78
(5) AF4 1/0.01 0x88
where i=1..n is the number of web servers assigned to AF4 2/0.02 0x90
each service class. This weight value is called Network AF4 3/0.03 0x98
Delay Product (NDP) of all web servers in one class, a pa- EF 0 0xb8
rameter is based on network delay measurements value min thresshold CBD value is more
and is set from experimental results to a value of a=0.2. If 2
than: ⋅ % BWshare ⋅ BW
responsiveness towards transient network delays that 3 ⋅ min(latency, ndelay )
packets suffer traversing the network (network with loosy
i
Ci
links) needs to be increased, then this value is better set to
a=0.7. Based on the number of active connections for each
3.5 ALBL/HSC prediction of scalability and BW
class at the web switch, ALBL/HSC algorithm calculates sharing
the active Class Bandwidth Delay (CBD) product metric ALBL/HSC algorithm has also the capability to predict
value per each class (See Eq. (6)).
scalability enhancements for each class based on the aver-
age connections per class and expected bandwidth share
Thri Thri increase or decrease for each class (these mechanisms
CBDi = Ci (b + (1 − b) ) ⋅ NDPi were not adapted into GRED but left as prediction met-
Ci Ci
rics for the administrator. Their adaptation is considered
(6)
future work). We describe these prediction mechanisms
separately at the following sections.
JOURNAL OF COMPUTING, VOLUME 3, ISSUE 2, FEBRUARY 2011, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG 8

3.5.1 ALBL/HSC scalability scalability prediction M/M/m system can be calculated as waiting time in the queue
We compare scalability of an M/M/1 queuing system of 1 in terms of an M/M/1 system as follows:
web server with an M/M/m system of m web servers.
Wq ⋅ ρ
Both systems use FIFO queues, utilize open queuing net- Wq ' = D (ρ )
works with random inter-arrival and service times (fol- ρ 2 + Wq (m − 1) m (8)
low non heavy tailed exponential distribution). We de-
From (8) it is obvious that as the number of web serv-
note as λ, λ’ and μ, μ’ average inter-arrival and service
ers’ increases in a cluster based web system (meaning
rates for M/M/1 and M/M/m systems accordingly, of infi-
scalability increase), waiting time in the queue of such
nite queuing length. Poisson process and exponential
system decreases in comparison to a single web server
distribution is assumed and usually used for simulation
system. What is also obvious from (8) is that HTTP wait-
of request and servicing rates of HTTP traffic (Moreover,
ing time in the queue of an M/M/m system is also highly
also more exponential heavy tailed distributions imprint
dependable on system utilization factor ρ. Meaning as the
more efficiently HTTP traffic characteristics and may be
utilization of such a system decreases we may achieve the
applicable). This is the case for HTTP traffic created from
same waiting times for HTTP requests with fewer web
independent sessions that correspond to bursty flows
servers m and as utilization increases we can keep con-
with large request spacing inside a session (inter-flow
stant waiting times by increasing the number of web
interval)[39]. For the M/M/1 system we have the follow-
servers the system utilizes accordingly. This is in fact true
ing: N = ρ and W = ρ , where Nq is the number of
q
1− ρ
q
µ (1 − ρ )
for a highly scalable balancing algorithm that can scale up
to a large number of web servers without adding signifi-
requests in the queue, Wq is the mean response time in
cant performance drawbacks to the whole system.
the queue and ρ =
λ
= 1 − p0 , is the utilization fraction of
µ Now let us assume that all m web servers of an
time the server is busy. Additionally, for the M/M/m sys- M/M/1 are fully busy with a factor Dm ( ρ ) → 1, Dm ( ρ ) = 0.999
tem we have: N 'q = Dm ( ρ ) ⋅ ρ' , where and f = 1 , we have: fq λ2 + µ 2 (m − 1) .That leads us to
m − ρ' q
Wq
fq ' = 0.999 ⋅
µ ⋅λ

Dm ( ρ ) =
ρm m
p
the all servers not available probability the following equation:
m! m − ρ 0
ρ' 1
and W ' = D ( ρ ) . m = 1 + fq ⋅ ρ 2 ( − 1), ρ ≤ 1
q m
λ ' (m − ρ ' ) ρ (9)
We make the following assumption that for both load From (9), it is obvious that there is a correlation between
balancing systems of 1 and m web servers, the request scalability of a multi-server system with the queue wait-
and service rates follow Poisson process distributions and
ing frequency fq of an M/M/1 system and parameter ρ.
converge to the same average rate values: λ=λ’and μ=μ’.
Based on this assumption, for the M/M/1 and M/M/m That is, scalability on an M/M/m system depends on cli-
queuing systems we see that there is a relationship be- ents request rate and servers response rate. Both request
tween the number of servicing web servers in a cluster and response rates can be calculated at the web-switch.
based web system and the rate of incoming HTTP re- Prediction of an increase or decrease in scalability per
quests at the web switch. That is, depending on the num- class of HTTP service is based on (9) (Scalability predic-
ber and rate of incoming requests scalability of a cluster tion equation. According to (9), the minimum number of
based system must converge to a specific number of web web servers needed to service requests for a class, which
server availability. In other words, if the HTTP request arrive at the web switch at a rate λ and receive service at a
rate decreases then clusters scaled up to a large number of λ
rate μ can be predicted, if we calculate . Our prediction
nodes (highly scalable) are not the best balancing solu- µ
Wq
tion in terms of performance. If we set as Ck = , then mechanism uses a λ calculated as λ = Cactive , where
ρ dt
ρ and C ' = ρ . There is a rela- Cactive the number of active connections for each class
Ck =
λ (1 − ρ )
k
λ (1 − ρ ) + λ (m − 1) CTime _ wait
and as µ = , the number of active connections
tionship between Ck and Ck ' : dt
1 1 λ (m − 1) that are left to TCP TIME_WAIT status. Based on the fol-
− = lowing equations and if λ ≤ µ , then from (9) we can
Ck ' Ck ρ
calculate the number of minimum web servers needed to
(7) deliver efficiently HTTP requests and the deviation pa-
From (7) we conclude that waiting time in the queue for an
JOURNAL OF COMPUTING, VOLUME 2, ISSUE 8, AUGUST 2010, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG 9

rameter according to the following for- 4 TESTBED SCENARIOS

m + 1 , where i=1,..n, the dt intervals
mula: ui = ln( i For the experimental scenarios, we used a web cluster of 2
)
mi and 5 web servers of equivalent processing power and
where mi value is calculated. Then a prediction deviation web content, connected to a 100Mbit web switch. Apache
version 2.2 is the web server software and the default pre-
parameter of the number of web servers to scale σ n2 is fork model MPM is used as processing memory manage-
calculated: σ n2 = 1
n
ment model by Apache for HTTP requests. We performed
n
∑
=1
i
ui 2 and the average deviation factor
cluster tests with httperf tool [51]. Web switch CPU oper-
ates at 2GHz with 1Gb of available memory. The operat-
σ2 is calculated using EWMA, with parameter λ=0.94
ing system of the web switch is a custom Linux OS that
over a series of k intervals of total duration T, where
n
uses Linux netfilter [13, 12] and Traffic Control tool (TC)
T = kc ⋅ ∑ dti and kc frequency parameter value that is for the queueing discipline process [44].
i =1 Experimental scenarios were performed into a cluster
set by the administrator: of 24 Quad Core Pentium clients that send HTTP requests
k (client farm) to the web servers that consist the cluster’s
σ 2 = ∑ λ ⋅ σ 2j + (1 − λ )u j web server farm. All web servers have the same web con-
j =1
tent and no content replication occurs. The generated
(10) HTTP requests are controlled by a central client node,
3.5.2 ALBL/HSC bandwidth sharing estimation assigned with the task of equal distributing HTTP request
Bandwidth increase/decrease prediction estimation per workload among client nodes. Each one of these requests
traffic class is based on the total number of connections tries to obtain random HTTP objects from the web serv-
that serviced on each one of the three probabilistic drop ers. The submission rate step (contention increase step) of
precedence states of each class and a ranking vector: the requests varies for each experiment accordingly. That
is, for each scenario, a fixed set of request rates per second
S = (r1, r 2, r 3) , where r1, r2, r3 the ranking set by ad-
is maintained until a total number of 24,000 requests are
ministrator, which corresponds to class with drop prece-
received and for each rate the following performance
dence x1,x2,x3 (where: r1+r2+r3=1 and r1:0.7..0.9,
metrics of the web cluster system are calculated:
r2:0.25..0.07 and r3:0.05..0.03) and IV vector Iv = (1,0,0) . -Average Throughput, in terms of average web cluster re-
Based on previous a bandwidth increase for a class at a sponse rate caused by an aggregate of HTTP client re-
BW fraction of: r2 ⋅ C 2 ⋅ + r3 ⋅ C3 ⋅ Thr i $ of the expected class quests.
C 2 + ⋅C3 That is the average throughput achieved by a bundle of
bandwidth if: n

fixed k requests per second: 1

∑ Thrk , until n re-
n k
∑i
n
=1
n k k =1
 C1   C1 
    quests are received.
(r1 , r2 , r3 ) ⋅  C2   Iv ⋅  C2  -Average Response time: We calculate response time as the
C  C  total response time of an aggregate of k HTTP requests.
 3  3
This value is then averaged until n HTTP requests are
(11)
serviced by the web-switch.
and the BW fraction given to a class (1..4) shall be a frac-
tion of the minimum BW available and BW fraction given -Scalability Factor (SF): We define as Scalability Factor (SF)
from (11) ( min( BWavailable , BWincrease _ fraction ) ). the percentage of HTTP traffic in terms of throughput our
One class may be in bandwidth decrease phase only if cluster gained as we increased the number of web servers
all connections for that class exist only in probabilistic that balance the clients from 2 to 5 web servers. It is calcu-
state AFx1 and at least one of the other classes ask for lated using the following equation:
bandwidth increase. BW decrease of a class if all connec- max Thr S = 5 − max Thr S = 2 , where
SFrate =
tions are in probabilistic state AFx1 for a period Tp fol- min(Thr s = 2 , Thr s = 5 )
lows a multiplicative decrease schema: BW ' = 3 BW .
class
2
class Thr s = 5 , Thr s = 2 , is the average throughput per request
Finally, if at least one class asks for bandwidth increase, rate experiment, using 5 and 2 web servers accordingly.
then the class with the most connections in probabilistic -CPU usage: This is the CPU average load per minute of
state AFx1 will be selected to perform an out-bound BW each load balancing algorithm operation measured at the
decrease that corresponds to the BW increase fraction. web switch, as a percentage over system utilization dur-
ing the respective period.
JOURNAL OF COMPUTING, VOLUME 3, ISSUE 2, FEBRUARY 2011, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG 10

In experimental scenarios I and II we investigate per-
formance and scalability of the following balancing algo-
rithms: Round Robin (RR), Least Connections (LC) and
Least Loaded (LL). Then we compare these results with
measurements of ALBL implementation. In experimental
scenario III, we investigate performance of ALBL/HSC
and ALBL, while also putting to the test CPU processing
efforts set by both algorithms at the web switch.
sive behavior pinpoints ALBLND aggressive characteris-
tics towards network congestion or web server load
change. While the aforementioned algorithms do not
have the sensitivity to detect network link changes and if
they do detect a load change may use conservative
mechanisms to mediate the problem (send one one re-

4.1 ALBL performance scenario I

In this scenario we put to the test the performance of RR,
LC, LLoad (LL) and ALBL balancing algorithms under a
case of a web server with limited network resources due
to congested network link paths. In order to achieve a
congested link, we shape the traffic that passes through
the first web server, using a Token Bucket Filter (TBF
queuing discipline) [48, 52, 13]. This queuing discipline
limits only the down-link bandwidth of the web server at
a rate of 2 Mbit/s, with the use of a queue, which size is
expressed in 250ms average latency and a burst value of
125Kbytes. The other web servers are connected to a
100Mbit link. HTTP clients request 10Kb of random ob-
jects from the web cluster. This operation is initially per-
formed at rate of 20 HTTP requests per second and then
the same experiment is repeated, each time with a conten-
Fig. 2. Scenario I, throughput in Kb/sec over low contention increase of
tion increase of 20 requests per second until a total num- clients Req/sec, over a total of 24,000 HTTP connections. ALBLND is
ber of 24,000 HTTP requests is reached. We also set the the ALBL algorithm that uses for weight calculation equation (2).
client request timeout value from 10 to 5 seconds in order quest to the least loaded server and each time check for
to insure that the bottleneck for the first web server will
mainly be its network link to the web switch and not a TABLE 2
100 HTTP REQUESTS AVERAGE THROUGH-
web server transient load. We put to the test ALBL algo-
PUT GAIN (KB/SEC) OF ALBLND OVER
rithm (ALBLND at Fig. 2) with a low threshold value that LC AND LLOAD ALGORITHMS
causes the network delay metric to be of importance for Req. Rate LC Thr Gain: LL Thr Gain:
the weight calculation process (use of (2)).
150-250 87.25 42
From Fig. 2, it is obvious that for low client request rate
250-350 99.75 62.2
values all algorithms perform the same in terms of
350-400 101.5 142.75
throughput (from 20 till 120 req/sec), with the exception
.
of LC algorithm that outperforms all tested algorithms at the one that has the least connections). On the other hand,
80, 100 req/sec and LLoad (LL) algorithm that fluctuates ALBLND can spot network congestion incidents using a
at 80 and 120 req/sec with an average deviation value of fine grained probing mechanism (max 10ms granularity
20 Kbytes/sec per 20 request bunch. RR shows the least on 100Mbit network- max 1ms granularity on Gbit net-
average throughput per bunch of requests. In contrast, work) and deal with them using a more aggressive ap-
ALBLND algorithm presents a linear performance which proach: Send a burst of requests to the least delayed web server
increases steadily for request rates below 120. Fluctua- and then probe again. Such an aggressive mechanism is not
tions of ALBLND above 120 provides a positive gain in successful when it comes to transient or random network
terms of throughput and does not fall bellow expected errors and in these cases ALBLND may lead the system to
linear behaviour of the algorithm. ALBLND average per- unbalanced conditions (That is why in such cases we use
formance gain in terms of throughput above 180 req/sec, the less responsive case derived from (1) equation for
is shown in Table 2. weight calculation of the ALBL algorithm.

This is proof that ALBLND matches successfully con- 4.2 ALBL scalability scenario II
gestion incidents at the first web server, due to its high
responsiveness towards changes in link network delay or In this scenario we put to the test LC, LLoad, ALBL (use
the web servers processing time of a request. This respon- of (1)) and ALBLND (use of (2)) algorithms scalability
 JOURNAL OF COMPUTING, VOLUME 2, ISSUE 8, AUGUST 2010, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG
with the use of the SF metric. In order to calculate SF val-
ues we retrieve a 10Kb object from the web cluster. This
operation is performed at rates that escalate from 20
HTTP till 400 HTTP requests per second using two web
servers behind the web switch and 1Kb object requests.
Then we change the number of web servers at the web
cluster from 2 to 5 and repeat the whole experiment. The
web servers used are of equivalent processing power and
not loaded.
SF metric shows the percentage of throughput gain of
the average throughput achieved by the previous algo-
rithms, if we increase the number of web servers in the
web farm from 2 to 5. As we can see in Fig. 3, LC algo-
rithm presents the highest throughput gain as we scale
from 2 to 5 web servers. Adaptive algorithms like LLoad
and ALBLND follow with an average difference of 0.08%
from LC algorithm. Finally, ALBL presents the worst
scalability factor that averages nearly 0.31% less than the
SF value of LC algorithm.
LC best scalability is due to the algorithms fast deci-
sions at the web switch that do not depend on complex
calculations or feedback information from the web serv-
ers. As the number of web server nodes increase, LLoad
algorithm depends on more feedback load information
from web servers. Increasing probing frequency of LLoad
leads its SF performance near the performance line of LC,
but still cannot outperform it. ALBLND algorithm (that
use equation (2) for the WC process) is also out-scaled by
LC due to algorithm agent performance at the web
Fig. 3. Scenario II, % clustering algorithms scaling factor SF over cli-
ents Req/sec.
switch. As probing agent frequency and responsiveness
decrease, ALBL algorithm scaling performance decreases
to a maximum value of 0.5% of that of LC algorithm scal-
ing performance. This is of course the case of a balancing
system where all network links are of equivalent network
capacities and all web servers have equal loads.
11
4.3 ALBL/HSC performance scenario III
In this scenario we examine performance of ALBL over
ALBL/HSC in a cluster based environment of 4 web serv-
ers where half the clients request a static HTTP content of
NCQ size (200-250Bytes random size object), while the
other half of the clients request HTTP content is of max
throughput size (download a large file over HTTP of
100MB size). This operation is performed at rates that
escalate from 40 to 400 HTTP requests per second (20
req/s for the first class and 20 for the second until 200
req/s for the first class and 200 for the second). This con-
tention increase mechanism ends when a total number of
24,000 HTTP requests have been successfully delivered
service. Firstly, we perform the test by using ALBL algo-
rithm weight calculation derived from (1). Then we per-
form the same experiment using ALBL/HSC and assign 2
web servers for servicing the NCQ class and 2 web serv-
ers for servicing the Max throughput class. We also send
packets arriving for other classes to the Max throughput
class. We adjusted expected BW parameter for both NCQ
and Max throughput classes to ½ BW of the available link
BW (100Mbit/s). That is, 6250 Kb/s and the maximum ex-
pected latency for each class based on a MTU package
length for the Max throughput class to 0.3ms. Accord-
ingly, we maintain an average 250Bytes packet size for
the NCQ class and latency of 0.05ms. Because ACK pack-
ets due to their small size, affect ALBL/HSC performance
we pass ACKs to both classes (ACKs to a Max throughput
packet via the Max throughput class, while ACKs for an
NCQ packet via the NCQ class).
Fig. 4. Scenario III(a), ALBL and ALBL/HSC Average HTTP response
time over client Requests for NCQ and Max Throughput traffic accord-
ingly
We calculate the average response time per aggregated
bunch of requests of ALBL and ALBL/HSC algorithms.
That is, for NCQ and Max Throughput HTTP classes. At
Fig. 4 ALBL/HSC NCQ class has less response time than
the NCQ traffic of the classless ALBL algorithm. This is of
course not the case for the ALBL/HSC Max throughput
class, which increases its average response time over the
Max throughput class of the ALBL algorithm. This can be
 JOURNAL OF COMPUTING, VOLUME 3, ISSUE 2, FEBRUARY 2011, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG
explained by the functionality of the class mechanism of
ALBL/HSC that favors small NCQ HTTP flows and limits
burstiness and aggressiveness of larger packet size HTTP
flows by setting an extra queuing delay to those packets
via the GRED mechanism (packet drops/ TCP retransmis-
sion and resetting of the TCP window size).
Fig. 5. Scenario III(b), ALBL and ALBL/HSC performance in terms of
Throughput over client Requests for both NCQ and Max Throughput
classes.
Favouring small packets over large ones is usually
beneficial for the overall system in terms of throughput. Fig. 6. Scenario III(c), Web switch % CPU performance of ALBL and
At Fig. 5, the average aggregated throughput of the num- ALBL/HSC algorithms over incoming connections request rate at the
web switch.
ber of requests (equal to the request rate) over request
rate, for both ALBL and ALBL/HSC algorithm is depicted.
For this case scenario results ALBL/HSC algorithm out-
performs ALBL by providing an average of 0.55 Kb/s
more throughput per HTTP request. Since average
throughput per HTTP request for all request rates using
ALBL algorithm is 4.5 Kb/s then ALBL/HSC performs in
general 12.2% better than ALBL algorithm in terms of
throughput.
4.3.1 ALBL/HSC and ALBL web switch CPU effort
scenario III(c)
We also calculated for the whole duration of each ex-
periment, average % CPU uptime value at the web
switch. % CPU uptime values range from 0.01 to 1.0 (It is
possible to have values greater that 1.0). The web switch
system enters CPU overloaded phase measured as abso-
lute uptime value above 0.9, while above 0.7 value is con-
sidered as critical and affects incoming HTTP traffic net-
work delay. % CPU processing time over the number of
simultaneous incoming HTTP requests at the web switch
is depicted at Fig. 6. The number of HTTP requests
reached for every requests rate experiment is a total of
24,000 HTTP requests.
It is obvious from Fig. 6, that ALBL/HSC utilizes 2.5 to 3
times more web switch CPU processing power that
ALBL, due to its complexity, class mechanism and layer-7
marking mechanism efforts. Also ALBL algorithm in-
creases web switch CPU utilization exponentially (Fig. 6,
12
ALBL, 280-400 req/sec) proportional to the increase of
request rate. This causes request rate to be a more critical
factor for the web switch forwarding capability than the
number of maintained connections. The paradox in this
case is that ALBL/HSC algorithm presents a more of loga-
rithmic increase in CPU processing power over request
rate. The only conclusion that can be clearly drawn by Fig
6., is that content aware algorithms with classes of service
need at least 60-200% more CPU processing effort than
adaptive content blind algorithms that use probing agents
or number of connections to balance accordingly among a
number of web servers. The profit of such performance
TABLE 3
AVERAGE % MORE CPU EFFORT OF ALBL/HSC
ALGORITHM THAN ALBL AND THROUGHPUT GAIN
OF ALBL/HSC 100 HTTP REQUESTS OVER ALBL IN
KB/SEC
Req. Rate ALBL/HSC ALBL/HSC
% more CPU Thr Gain
effort: (Kb/s):
40-60 60 46.2
200-280 190 140.07
320-400 130 202.01
.
gains in our case is presented at Table 3. In conclusion, for
a throughput gain of 120 KB/s that is provided by a con-
tent aware algorithm 126% more CPU effort is required
than a content blind load balancing algorithm. That is,
setting the threshold to 1% more CPU effort of
ALBL/HSC may lead to 1 KB/s throughput gain over
ALBL.
CONCLUSION
In this paper we present ALBL balancing algorithm for
cluster based web systems. ALBL main advantage is that
takes into account web servers CPU load as well as net-
work conditions for the balancing process.
JOURNAL OF COMPUTING, VOLUME 2, ISSUE 8, AUGUST 2010, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG
We also present ALBL/HSC, a content aware balancing
algorithm that uses ALBL mechanism for the balancing
process among web servers that service requests for the
same service class. ALBL/HSC algorithm is capable of
differentiating HTTP requests into service classes and
provides different drop probabilities for each class based
on NDP and CBD metric values. It also has the ability to
predict the need of scalability or bandwidth in-
crease/decrease per service class. Incorporation of predic-
tion metrics to the algorithm is considered as future work.
We compare performance of ALBL algorithm against
known stateless, stateful and adaptive algorithms and
performance of ALBL/HSC over ALBL. From the experi-
mental results we show that ALBL matches or even over-
comes the performance of conventional balancing algo-
rithms. In particular, ALBL balances efficiently HTTP
traffic on unbalanced conditions that dynamically change:
(a) Due to utilized network conditions and (b) due to web
server limited computational resources, while adequate
network resources exist. We also confirm ALBL algorithm
scalability potential (used as a base balancing algorithm
by ALBL/HSC).
Finally, we show with performance measurements of
ALBL/HSC over ALBL, the significant performance gains
of content aware balancing strategies over non content
aware ones, as well as the processing efforts at the web
switch that emerge. Further reduction of ALBL/HSC
processing overhead at the web switch and incorporation
of bandwidth and scalability estimation process metrics
into ALBL/HSC, is set for investigation and future work.
ACKNOWLEDGMENT
We would like to thank Democritus University of Thrace
Dept. of Electrical and Computer Eng., Data analysis
laboratory for the permit to use their laboratory equip-
ment to perform our tests. We also would like to thank
Elec. Eng. Panagiotis Nestoras (pnestora at ee.duth.gr) for
his technical advice and assistance at the conduct of the
experimental scenarios.
REFERENCES
[1] V. Cardellini, E. Casalicchio, M. Colajanni, and P. S.
Yu, “The State of the Art in Locally Distributed Web-Server
Systems,” ACM Computing Surveys, vol. 34, no. 2, pp. 263–311,
2002.
[2] V. Cardellini, M. Colajanni, and P. S. Yu, “Dynamic
load balancing on web server systems,” IEEE Internet Compu-
ting, vol. 3, no. 3, pp. 28–39, 1999.
[3] CISCO, “Distributed Director,” http://-
www.cisco.com/warp/public/cc/pd/cxsr/dd/, 2004.
[4] SQUID, “web proxy cache,” http://www.squid-
cache.org, 1995.
[5] D. Wessels and K. Claffy, “Internet Cache Protocol
(ICP) version 2,” RFC 2186, 1997.
13
[6] D. Maltz and P. Bhagwat, “TCP splice application
layer proxy performance,” High Speed Networks, vol. 8, no. 3,
pp. 225 – 240, 1999.
[7] S. Adhya, “Asymmetric TCP Splice: A Kernel Me-
chanism to Increase the Flexibility of TCP Splice, Master The-
sis,” http://www.cse.iitk.ac.in/research/mtech1999/-
9911134.ps.gz, 2001.
[8] S. Purkayastha, “Symmetric TCP Splice: A Kernel
Mechanism for High Performance Relaying,” Dept. of C.S.
Indian Institute of Technology, Tech. Rep., 2001. [Online].
Available: http://www.cse.iitk.ac.in/research/mtech1999/-
9911140.ps.gz
[9] L. Wang, “Design and Implementation of TCPHA -
Draft release,” http://dragon.linux-vs.org/dragonfly/, 2005.
[10] M.-Y. Luo and C.-S. Yang, “Efficient support for con-
tent-based routing in web server clusters,” in Proc. of 2nd
USENIX Symposium on Internet Technologies and Systems, 1998.
[11] H.-H. Liu, M.-L. Chiang, and M.-C. Wu, “Efficient
support for content-aware request distribution and persistent
connection in web clusters,” Software Practise & Experience,
vol. 37, no. 11, pp. 1215 – 1241, 2007.
[12] Layer7filter, “Linux Layer7 filter Team: Application
Layer Packet Classifier for Linux,” http://l7-
filter.sourceforge.net/, 2004.
[13] Netfilter, “Linux Netfilter Project,” http://-
www.netfilter.org, 2000.
[14] L. Aversa and A. Bestavros, “Load Balancing a Clus-
ter of Web servers using Distributed Packet Rewriting,” in
Proc. of IEEE International Performance, Computing and Commu-
nications conference, 2000, pp. 24–29.
[15] M. Colajanni, P. S. Yu, and D. M. Dias, “Analysis of
task assignment policies in scalable distributed Web-server
systems,” IEEE Trans. on Parallel and Distributed Systems, vol. 9,
pp. 585–600, 1998.
[16] CISCO, “CISCO Services Modules - Understanding
CSM Load Balancing Algorithms,” http://www.cisco.com/-
warp/public/117/csm/lb_algorithms.pdf, 2007.
[17] W. Zhang, “Build highly-scalable and highly-
available network services at low cost,” Linux Magazine, vol. 3,
pp. 23–31, 2003.
[18] A. Weinrib and S. Shenker, “Greed is not enough:
Adaptive load sharing in large heterogeneous systems,” in
Proc. of IEEE INFOCOM, 1988, pp. 986–994.
[19] B. Abhay and C. Sanjay, “Performance evaluation of
web servers using central load balancing policy over virtual
machines on cloud,” in Proc. of COMPUTE: The Third Annual
ACM Bangalore Conference. New York, NY, USA: ACM, 2010,
pp. 1–4.
[20] J. Batheja and M. Parashar, “A framework for Adap-
tive Cluster Computing Using Javaspaces,” Cluster Computing,
vol. 6-3, no. 3, pp. 201–213, 2003.
[21] N. Handigol, S. Seetharaman, N. McKeown, and
R. Johari, “Plug-n-serve: Load-Balancing Web Traffic using
OpenFlow,” in Proc. of ACM SIGCOMM, 2009, pp. 88–95.
JOURNAL OF COMPUTING, VOLUME 3, ISSUE 2, FEBRUARY 2011, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG
[22] D. Maltz and P. Bhagwat, “Linux Director: a connec-
tion director fo scalable network services,” Computer Science
and Technology, vol. 15, no. 6, pp. 560 – 571, 2000.
[23] P. O’Rourke and M. Keefe, “Performance Evaluation
of Linux Virtual Server,” in Proc. of the 15th LISA System Ad-
ministration Conference, 2001, pp. 79–92.
[24] M. Andreolini and S. Casolari, “Load prediction
models in web-based systems,” in Proc. of the 1st international
conference on Performance evaluation methodolgies and tools.
ACM, 2006, p. 27.
[25] M. Andreolini, S. Casolari, and M. Colajanni, “Mod-
els and Framework for Supporting Runtime Decisions in
Web-Based Systems,” ACM Transactions on the Web., vol. 2,
no. 3, pp. 17–43, 2008.
[26] V. Cardellini, M. Colajanni, and P. S. Yu, “Geograph-
ic load balancing for scalable distributed Web systems,” in
Proc. of the 8th International Symposium on Modeling, Analysis
and Simulation of Computer and Telecommunication Systems,
2000, pp. 20–28.
[27] S. Sharifian, S. Motamedi, and M. Akbari, “A predic-
tive and probabilistic load-balancing algorithm for cluster-
based web servers,” Applied Soft Computing, vol. 5, no. 1, pp.
174–186, 2010.
[28] J. Cao, Y. Sun, X. Wang, and S. K. Das, “Scalable load
balancing on distributed web servers using mobile agents,”
Parallel and Distributed Computing, vol. 63, no. 10, pp. 996–1005,
2003.
[29] B. Boone, S. Van Hoecke, G. Van Seghbroeck,
N. Joncheere, V. Jonckers, F. De Turck, C. Develder, and
B. Dhoedt, “Salsa: QoS-aware load balancing for autonomous
service brokering,” Systems & Software., vol. 83, no. 3, pp. 446–
456, 2010.
[30] E. Casalicchio and M. Colajanni, “A client-aware
dispatching algorithm for web clusters providing multiple
services,” in Proc. of the 10th international conference on World
Wide Web. ACM, 2001, pp. 535–544.
[31] M.-Y. Luo, C.-S. Yang, and C.-W. Tseng, “Content
management on server farm with Layer-7 routing,” in Proc. of
ACM symposium on Applied Computing. ACM, 2002, pp. 1134–
1139.
[32] L. Cherkasova and M. Karlsson, “Scalable Web Serv-
er Cluster Design with Workload-Aware Request Distribution
Strategy WARD,” in Proc. of the 3rd International Workshop on
Advanced issues of E-Commerce and Web-Based Information Sys-
tems. Society Press, 2001, pp. 212–221.
[33] M.-L. Chiang, Y.-C. Lin, and L.-F. Guo, “Design and
implementation of an efficient web cluster with content-based
request distribution and file caching,” Systems and Software,
vol. 81, no. 11, pp. 2044–2058, 2008.
[34] V. S. Pail, M. Aront, G. Bangat, M. Svendsent,
P. Druschel, W. Zwaenepoelt, and E. Nahum, “Locality-
Aware Request Distribution in Cluster-based Network Serv-
ers,” in Proc. of the 8th International conference on Architectural
Support for Programming Languages and Operating Systems, 1998.
14
[35] E. Casalicchio and Colajanni, “A Client-Aware Dis-
patching Algorithm for Web Clusters providing multiple ser-
vices,” in In proc. of the 10th WWW conference, 2002.
[36] M.-L. Chiang, C.-H. Wu, Y.-J. Liao, and Y.-F. Chen,
“New content-aware request distribution policies in web clus-
ters providing multiple services,” in Proc. of the 2009 ACM
symposium on Applied Computing. ACM, 2009, pp. 79–83.
[37] A. Karakos, D. Patsas, A. Bornea, and
S. Kontogiannis, “Balancing HTTP traffic using dynamically
updated weights, an implementation approach,” in Proc. of the
10th Panhellenic Conference on Informatics, 2005, pp. 873–878.
[38] S. Kontogiannis, S. Valsamidis, P. Efraimidis, and
A. Karakos, “Probing based load balancing fo web server
farms,” in Proc. of the 13th Panhellenic Conference on Informatics,
2009, pp. 175–180.
[39] S. B. Fred, T. Bonald, A. Proutiere, G. Régnié, and
J. W. Roberts, “Statistical bandwidth sharing: a study of con-
gestion at flow level,” ACM SIGCOMM Comput. Commun.
Rev., vol. 31, no. 4, pp. 111–122, 2001.
[40] M. Andreolini, E. Casalicchio, M. Colajanni, and
M. Mambelli, “A Cluster-Based Web System Providing Diffe-
rentiated and Guaranteed Services,” Cluster Computing, vol. 7,
no. 1, pp. 7–19, 2004.
[41] Z. Lin, L. Xiao-ping, and S. Yuan, “A content-based
Dynamic Load-Balancing Algorithm for Heterogeneous Web
Server Cluster,” Computer Science and Information Systems,
vol. 7, no. 1, pp. 153 – 162, 2010.
[42] L. Mamatas and V. Tsaoussidis, “A new approach to
Service Differentiation: Non-Congestive Queueing,” in Proc. of
International Workshop on Convergence of Heterogeneous Wireless
Networks, 2005, pp. 78–83.
[43] L. Mamatas and V. Tsaoussidis, “Differentiating Ser-
vices with Non-Congestive Queuing (NCQ),” IEEE Transac-
tions on Computers, vol. 58, no. 5, pp. 591 – 604, 2009.
[44] TC, “Linux Traffic Control Project,” http://lartc.org/,
2001.
[45] W. Almesberger, J. H. Salim, and A. Kuznetsov,
“Generalized Random Early Drop queueing discipline,”
http://http://www.opalsoft.net, 2006.
[46] S. Floyd and V. Jacobson, “Random early detection
gateways for congestion avoidance,” IEEE ACM Transactions
on Networks, vol. 1, no. 4, pp. 397–413, 1993.
[47] M. Christiansen, K. Jeffay, D. Ott, and S. F. Donelson,
“Tuning RED for Web Traffic,” in Proc. of ACM SIGCOMM,
2000, pp. 139–150.
[48] B. Hubert, G. Maxwell, R. Van Mook,
M. Van Oosterhout, P. Schroeder, J. J. Spaans, and P. Larroy,
“Linux Advanced Routing and Traffic Control HOWTO,”
http://www.tldp.org/HOWTO/Adv-Routing-HOWTO, 2004.
[49] S. Floyd, “Recomendations on using the gentle va-
riant of RED,” http://www.icir.org/floyd/red/gentle.html,
2000.
JOURNAL OF COMPUTING, VOLUME 2, ISSUE 8, AUGUST 2010, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG 15

[50] W. Chen and S.-H. Yang, “The mechanism of adapt-

ing RED parameters to TCP traffic,” Computer Communications,
vol. 32, no. 13-14, pp. 1525–1530, 2009.
[51] D. Mosberger and T. Jin, “A Tool for Measuring Web
Server Performance,” in Proc. of ACM Workshop on Internet
Server Performance. ACM, 1998, pp. 59–67.
[52] E. Magana, E. Izkue, and J. Villadangos, “Review of
traffic scheduler features on general purpose platforms,” in
Proc. of SIGCOMM Workshop on Data communication in Latin
America and the Caribbean, 2001, pp. 50–79.

S. Kontogianns is a PhD candidate student at the Dept. of Electrical

and Computer Eng., Democritus University of Thrace, Xanthi,
Greece. He received a five-year Eng. diploma and MSc in Software
Eng. from Department of Electrical and Computer Eng., Democritus
University of Thrace. His research interests are in the areas of Dis-
tributed systems, computer networks, middlware protocol design,
network modelling and computer networks performance evaluation.
His e-mail is: skontog at ee.duth.gr.

S. Valsamidis is a PhD candidate student at the Dept. of Electrical

and Computer Eng., Democritus University of Thrace, Xanthi,
Greece. He received a five-year Electrical Eng. diploma from De-
partment of Electrical Eng., University of Thessaloniki, Greece and
MSc in Computer Science from University of London, UK. He is an
Applications Prof. in the Dept. of Information Technology, TEI of
Kavalas, Greece. His research interests are in the areas of Distrib-
uted systems, computer networks, database architectures, data
analysis and evaluation and data mining. His e-mail is: svalsam at
ee.duth.gr.

A. Karakos received the Degree of Mathematician from the Depart-

ment of Mathematics from Aristoteles University of Thessaloniki,
Greece and the Maitrise d' Informatique from the university PIERRE
ET MARIE CURIE, Paris. He completed his PhD studies at university
PIERRE ET MARIE. He is Assistant Professor at the Dept. of Elec-
trical and Computer Eng., Democritus University of Thrace, Greece.
His research interests are in the areas of Distributed systems, data
analysis and programming languages. His e-mail is: karakos at
ee.duth.gr.