Designing in a Distributed World - The Practice of Cloud System Administration - page 22

able to remeasure and adjust the design if we discover our estimates and prototypes have
not guided us as well as we had hoped.
At the start of the design process we often create many designs, estimate how fast each
will be, and eliminate the ones that are not fast enough. We do not automatically select the
fastest design. The fastest design may be considerably more expensive than one that is suf-
ficient.
How do we determine if a design is worth pursuing? Building a prototype is very time
consuming. Much can be deduced with some simple estimating exercises. Pick a few com-
montransactionsandbreakthemdownintosmallersteps,andthenestimatehowlongeach
step will take.
Two of the biggest consumers of time are disk access and network delays.
Disk accesses are slow because they involve mechanical operations. To read a block of
data from a disk requires the read arm to move to the right track; the platter must then spin
until the desired block is under the read head. This process typically takes 10 ms. Compare
thistoreadingthesameamountofinformationfromRAM,whichtakes0.002ms,whichis
5,000 times faster. The arm and platters (known as a spindle ) can process only one request
at a time. However, once the head is on the right track, it can read many sequential blocks.
Therefore reading two blocks is often nearly as fast as reading one block if the two blocks
are adjacent. Solid-state drives (SSDs) do not have mechanical spinning platters and are
much faster, though more expensive.
Networkaccessisslowbecauseitislimitedbythespeedoflight.Ittakesapproximately
75 ms for a packet to get from California to the Netherlands. About half of that journey
time is due to the speed of light. Additional delays may be attributable to processing time
on each router, the electronics that convert from wired to fiber-optic communication and
back, the time it takes to assemble and disassemble the packet on each end, and so on.
Two computers on the same network segment might seem as if they communicate in-
stantly, but that is not really the case. Here the time scale is so small that other delays have
a bigger factor. For example, when transmitting data over a local network, the first byte ar-
rives quickly but the program receiving the data usually does not process it until the entire
packet is received.
Inmanysystemscomputationtakeslittletimecomparedtothedelaysfromnetworkand
disk operation. As a result you can often estimate how long a transaction will take if you
simply know the distance from the user to the datacenter and the number of disk seeks re-
quired. Your estimate will often be good enough to throw away obviously bad designs.