Review: LARD

From: Jing Su <jingsu_REMOVE_THIS_FROM_EMAIL_FIRST_at_cs.toronto.edu>
Date: Sun, 25 Sep 2005 23:52:42 -0400

SUMMARY

The primary observation of this paper is that performance of backend
cluster nodes can be improved by weighing front-end load balancing
with request type affinity. By increasing request type affinity on
backend nodes, cache and in-core data hits will increase. Note that
this is not a partitioning scheme -- all nodes are capable of
servicing any request. Thus, it is a "soft" partition, which can
change due to varying demands.

Their proposal rests on a more sophisticated front-end which receives
and examines the client connection, and then decides how to
preferentially redirect the request invisibly to the backend. Their
results show that while weighted round robin (WRR) is indeed good at
balancing load, it fails to take into account cache and memory miss
performance penalties.

In addition to their primary goal they also design a transparent
handoff protocol from the front-end to the selected backend, invisible
to the client. This is necessary because the front-end is now
heavier, and must accept the client connection first in order to
perform a request-type preferential selection.

KEY STRENGTHS

The key strength of this paper is their solution for providing a load
balancer that has a request-type affinity for selected servers. They
clearly show how traditional WRR systems failed to recognize the
impact of cache misses, and how their solution addresses this issue
and improves performance.

More interestingly, their solution shows how a system might be
automated, to provide cluster reconfiguration to adjust for
dynamically changing loads. Node partitioning, for example, is a
static solution and does not address changing loads. One can imagine
loads changing throughout the day, but having a periodic pattern. An
automated solution could dynamically adjust so that the system always
serves at peak performance.

KEY WEAKNESSES

The biggest weakness of this paper is the added responsibility placed
on this front-end. Because this machine is now a critical part of
distributing work, its failure would be a major impedance to providing
service. One solution would having several front-ends, connected by a
traditional WRR layer-7 switch. However, the paper does not discuss
how multiple front-ends might cooperate.

The paper also claims that front-ends will have ample computing
resources to deal with redirection decisions. I am unconvinced this
is a reasonable assumption. First, accepting TCP connections and
examining the request type is expensive, and might overload the
front-end on burst crowds, despite ample power during steady-state
periods. Second, I'm not convinced the traces they gathered are from
heavy traffic sites which truly stress the capacities of the
front-end.
Received on Sun Sep 25 2005 - 23:52:54 EDT

This archive was generated by hypermail 2.2.0 : Sun Sep 25 2005 - 23:59:22 EDT