The product DQ, that is the data server query, and the rate of query
that is coming into the server. This DQ represents some sort of system limit for
a given server capacity the product DQ
is a constant. Said differently for a different
system capacity, we can increase the number of clients that we are serving if we
reduce the amount of data that we're
using to process the incoming queries. That is,
we're increasing Q by decreasing the harvest or D. Or can do the opposite and
that is, we can entertain a smaller set of queries. That is the yield will come
down but we will be able to give the complete data that is needed
for serving that query. An example of would
be, if I am a client that is accessing
a server for my mail, I would want to get all my mail, not part of the mail.
So in that case, I will be happy if the server gives me a harvest of one, even
it means that not all the incoming clients maybe
served by the server due to the capacity limitation
of the server at any point of time. So as a system administrator, we have some
choices to play with. The important thing is
that in giant's scale services. The performance is limited
by network and not by the I/O capacity. We can have as much I/O capacity as we
want by having more hardware resources here, but
what we are bound by is the network capacity.
So if we increase the capacity of a server, we have a choice as a system
administrator. We can either increase the harvest, keeping
the yield the same. Or, we can increase the
number of clients we are serving. That is,
we can increase the yield, keeping D a
constant. That's the knob that a system administrator
can play with in terms of dealing with capacity
increases at the server. Similarly, if I am
a system administrator, and some nodes in the server
fail, then again we have a choice of
either decreasing the harvest or decreasing the yield, in
order to deal with reduced DQ value. Of
course, it all depends on how the server itself
is architected, if the failures can be hidden
through replication and so on. But the important message
I want to convey to you is that this DQ represents a system constant, so far
as the server is concerned, in terms of
the capacity. Given a particular capacity of the
server, DQ is fixed. So as a system
administrator you have a choice of either sacrificing
yield for harvest or harvest for yield. You
cannot increase both the harvest and yield without
increasing the server capacity. At traditional measure that has been used in
servers, is the notion of IOOPS, or I/O operations per second, and these are
meaningful in database kinds of applications.
Where the applications are disbound, but the
giant scale applications are network bound,
and for network bound applications this manager
DQ is much more intuitive as to what is going on in terms of managing the
incoming load to the server - And managing
the corpus of data that the server has
to look at in order to satisfy incoming
queries. Another metric that system administrators have often
used is what is called up time. You
may have heard of terminologies like mean time
between failure and mean time to repair.
Meantime between failure is, what is the expected
time between two successive failures inside a
data center? And similarly meantime to repair is
if a failure is detected, how much time does it take to bring up a failed
server, that need time to repair. And the up-time is defined as the ratio of
the difference between, mean time between failure and MTTR, that is mean time to
repair, and MTBF, that is uptime is equal to MTBF minus MTTR
divided my MTBF. That is uptime. And you want the the uptime to be
close to one. And usually uptime is measured in nines. Meaning point nine,
nine, nine, nine. Five nines or six nines and so on. So you want the up time to
be as close to one as possible for giant scale services. But again, this up time
as a metric is not very satisfying because
if there are no queries giving the time that
is needed for repairing, that is, during the MTT
par, the mean time to repair, if no queries
come into the server, then you haven't
made anybody unhappy. In that sense, the uptime
is not a very intuitive measure of how well a server is performing. It is better
to look at yield as the output metric. And the harvest, again, is the output
metric for say how well a server is able to deal with the dynamism and scale of
requesting handled by a particular giant-scale service. We'll
see that this DQ principle is very powerful
in advising the system administrator on how to
architect the system. How much to replicate? How
much to partition in terms of the data set that the server is handling? How to
deal with failures? How to gracefully degrade the
servers when the volume of incoming traffic increases
beyond a server capacity? All of these are questions that
can be handled very elegantly using the DQ principle. And
the key underlying assumption in the DQ principle, is that
the giant scaled services are network bound, and not I/O bound.