26-03-2014, 03:58 PM
Splitting HTTP Requests on Two Servers
Abstract
Many techniques are commonly used to increase
server availability or for distributing the load among a group
of servers. We propose a technique for splitting a single HTTP
request that allows a TCP connection to be dynamically split
between two Web servers without using a central control. For
example, one server can handle connection establishment and
closing, while another handles the data transfer. This
approach requires no client involvement since the existing
connection with the initial server continues to be maintained,
and the client is completely unaware of the splitting. We
demonstrate the splitting concept in a LAN environment and
provide related performance results that highlight several
interesting features of splitting. The splitting was done using
two bare PC servers with no operating system (OS) or kernel
running in the machines. Splitting also works with clients
located anywhere on the Internet, although servers have to be
located on the same LAN. Our implementation and results
indicate the feasibility of splitting TCP connections to
transparently redistribute server load without client
involvement.
INTRODUCTION
Web server reliability and load distribution among Web
servers are important problems that continue to be
addressed using a variety of techniques. In particular, load
balancing techniques are used at various layers of the
protocol stack to share the load among a group of Web
servers [19], [20]. Alternatively, in approaches such as
Migratory TCP (M-TCP) [13], a client connection is
migrated to a new server and an adaptation of TCP enables
migration of the connection state. We propose a technique
for splitting a TCP connection between Web servers that
allows one server to handle connection establishment and
another to handle data transfer. Splitting also allows a
server to self-delegate a percentage of its connection
requests to another server for data transfer. Splitting TCP
connections in this manner enables servers to share the load
without a central control and without any client
involvement.
SPLIT ARCHITECTUR
The split architecture used for the experi
iments described
in this paper is illustrated in Figure 2. Although these
experiments were conducted in a LAN e
environment, as
noted earlier, the proposed splitting tech
hnique does not
require that the set of clients {C} be conn
nected to a LAN
(they can be located anywhere on the Inte
ernet). The only
requirement is that the servers be connect
ted to the same
LAN for the reasons discussed below. However, this
requirement does not limit the scope o
or scalability of
splitting since many real-world Web serv
ver clusters are
located within the same LAN. The clients send requests to
servers S1 or S2. S1 and S2 are referred to as split servers.
For a given request, the connection server (
(CS) handles the
{CE, CT} phases of a connection, and its d
delegated server
S2 (DS) handles the {DT} phase. Similarly
y, S2 can act as a
server for a client’s request and its DS w
will be S1. The
clients do not have any knowledge of a DS. A given request
using the DS. In
can also be processed by the CS without u
general, there can be a set of n (≥ 2) s
servers that can
delegate requests to each other.
PERFORMANCE MEASUREMENTS
Experimental Setup
The experimental setup involved Dell Optiplex GX260
PCs with Intel Pentium 4, 2.8GHz Processor, 1GB RAM
and Intel 1G NIC on the motherboard. A LAN is set up for
the experiments using a Linksys 16 port GB switch. Linux
clients are used to run the http_load [17] stress tool and a
bare PC Web client. Each http_load stress tool can run up
to 1000 concurrent HTTP requests per sec. Each bare PC
Web client can run up to 5700 HTTP requests per sec. A
mixture of bare and Linux clients along with bare split
servers are used to measure the performance. In addition,
we tested the split servers with popular browsers running
on Windows and Linux (Internet Explorer and Firefox
respectively).
CONCLUSION
In this paper, we showed how to split an HTTP request
and the underlying TCP connection between the two
servers. We presented the split architecture and provided
the relevant design and implementation details. However,
the idea is demonstrated using BMC (bare PC) servers as
splitting would be much harder to implement using OS-
based servers. The experimental results indicate that when
HTTP requests are split using two servers and delegation is
done in both directions (25% delegation to each other), the
maximum capacity is 14,428 requests/sec (the theoretical
limit is 16,000 for two servers). Splitting scalability was
found to be 1.8035 for two servers (i.e., there is an
approximately 10% overhead due to splitting). With respect
to increasing the file size, it was seen that performance is
similar with or without splitting. Moreover, the splitting
percentage does not have much impact for larger file sizes.
The novel splitting technique and associated Web server
architecture introduced in this paper have potential
applications in distributed computing and improving server
reliability.