# Efficiency & Scalability

## Alex Boisvert - 19 Apr 2013

Software engineers know that distributed systems are often hard to scale and many can intuitively point to reasons why this is the case by bringing up points of contention, bottlenecks and latency-inducing operations. gIndeed, there exists a plethora of reasons and explanations as to why most distributed systems are inherently hard to scale, from theCAP theoremto scarcity of certain resources, e.g., RAM, network bandwidth ...

It's said thatgood engineersknow how to identify resources that may not appear to be relevant to scaling initially but will become more significant as particular kinds of demand grow. If that’s the case, thengreat engineersknow that system architecture is often the determining factor in system scalabilityg—that a system’s own architecture may be its worse enemy — so they define and structure systems in order avoid fundamental flaws.

In this post, I want to explore the relationship between system efficiency and scalability in distributed systems;they are to some extent two sides of the same coin. gWe’ll consider specifically&two common system architecture traits: &replicationandrouting. &Some of this may seem obvious to some of you but it’s always good to back intuition with some additional reasoning.

Before we go any further, it’s helpful to formulate a definition of efficiency applicable to our context:

**efficiency** is the extent to which
work is performed relative to the total work and/or cost incurred.

We’ll also use the following definition of scalability,

**scalability** is the ability of a system to accommodate an increased workload by repeatedly applying a cost-effective strategy for extending a system’s capacity.

So, scalability and efficiency are both determined by cost-effectiveness with the distinction that scalability is a measure of marginal gain. gStated differently,if efficiency decreases significantly as a system grows, then a system is said to be **non-scalable**.

Enough rambling, let’s get our thinking caps on! gSince we’re talking about distributed systems, it’s practically inevitable to compare against traditional single-computer systems, so we’ll start with a narrow definition of system efficiency:

```
average work for processing a request on a single computer
Efficiency = ——————————————————————————————————————————————————————————
average work for processing a request in distributed system
```

This definition is a useful starting point for our exploration because it abstracts out the nature of the processing that’s happening within the system; it’s overly simple but it allows us to focus our attention on the big picture.

More succinctly, we'll write:

```
(1) Efficiency = Wsingle / Wcluster
```

## Replication Cost

Many distributed systems replicate some or all of the data they process across different processingnodes(to increase reliability, availability or read performance) so we can model:

```
(2) Wcluster = Wsingle + (r x Wreplication)
```

where `r`

is the number of replicas in the system and
`Wreplication`

is the work required to replicate the data to other nodes.
`Wreplication`

is typically lower than `Wsingle`

, though realistically they have different cost models (e.g.,
`Wsingle`

may be CPU-intensive whereas `Wreplication`

may be I/O-intensive). If `n`

is the number of nodes in the system, then `r`

may be as large as `(n-1)`

, meaning replicating to all other nodes, though most systems will only replicate to 2 or 3 other nodes — for good reason&—as we’ll discover later.

We’ll now define the replication coeffient, which expresses the relative cost of replication compared to the cost of processing the request on a single node:

```
(3) Qreplication = Wreplication / Wsingle
```

Solving for `Qreplication`

, we get:

```
(4) Wreplication = Qreplication x Wsingle
```

If we substitute `Wreplication`

in (2) by the equation formulated in (4), we obtain:

```
(5) Wcluster = Wsingle x [ 1 + ( r x Qreplication * Wsingle ) ]
```

We now factor out `Wsingleton`

from the left side:

```
(6) Wcluster = Wsingle x [ 1 + r * Qreplication ]
```

Taking the efficiency equation (1) and substituting `from (6)`

, the equation becomes:

```
(7) Efficiency = Wsingle / [ Wsingle x ( 1 + r * Qreplication ) ]
```

We then simplify `Wsingle`

to obtain the final efficiency for a replicating distributed system:

```
(8) Efficiency (replication) = 1 / [ 1 + (r x Qreplication) ]
```

As expected, both r and `Qreplication`

are critical factors determining efficiency.

Interpreting this last equation and assuming `Qreplication`

is a constant inherent to the system’s processing, our two takeaways are:

- If the system replicates to all other nodes
`(i.e.,r = n - 1)`

it becomes clear that the efficiency of the system will degrade as more nodes are added and will approach zero asnbecomes sufficiently large.

To illustrate this, let's assume `Qreplication = 10%`

- Efficiency (r = 1, n = 2) = 91%
- Efficiency (r = 2, n = 3) = 83%
- Efficiency (r = 3, n = 4) = 76%
- Efficiency (r = 4, n = 5) = 71%
- Efficiency (r = 5, n = 6) = 67%
- ...

In other words, **fully-replicated distributed systems don't scale.**

- For a system to scale, the replication factor should be a (small) constant.

Let's illustrate this with `Qreplication`

fixed at 10% and using a replication factor of 3,

- Efficiency (r = 3, n = 4) = 76%
- Efficiency (r = 3, n = 5) = 76%
- Efficiency (r = 3, n = 6) = 76%
- Efficiency (r = 3, n = 7) = 76%
- Efficiency (r = 3, n = 8) = 76%
- ...

As we can see, **fixed-replication-factor distributed systems scale** - although, as you might expect, they do not exhibit the same efficiency as a single-node system. At worse, the efficiency will be `1/r`

— as you would intuitively expect.

## Routing Cost

When a distributed system routes requests to nodes holding the relevant information (e.g., a partially replicated system, `r < n`

) its working model may be defined as,

```
(9) Wcluster = (r / n) * Wsingle + (n-r)/n * (Wrouting + Wsingle)
```

The above equation represents the fact that `r`

out of `n`

requests are processed locally whereas the remainer of the requests are routed and processed on a different node.

Let’s define the routing coefficient to be,

```
(10) Qrouting g= &Wrouting / Wsingle
```

Solving for `Wrouting`

in (9) by (11) to obtain,

```
(12) Wcluster = (r/n) * Wsingle g+ &(n-r)/n * [ (Qrouting * Wsingle) + Wsingle ]
```

and taking the efficiency equation (1), substituting from (12), the simplified equation becomes:

```
(13) Efficiency (routing) = n / [ n + (n - r) * Qrouting ]
```

Looking at this last equation, we can infer that:

As the system grows and n goes towards infinity, the efficiency of the system can be expressed as 1 / (1 + Qrouting). The efficiency is not dependent on the actual number of nodes within the system therefore routing-based systems generally scale. (But you knew that already)

If the number of nodes is large compared to the replication factor (n >> r) and Qrouting is significant (1.0, same cost as Wsingle), then the efficiency is ½, or 50%. This matches the intuition that the system is routing practically all requests and therefore spending half of its efforts on routing. The system is scaling linearly but it’s costing twice as much to operate (for every node) compared to a single-node system.

If the cost of routing is insignificant (Qrouting = 0), the efficiency is 100%. That’s right, if it doesn’t cost anything to route the request to a node that can process it, the efficiency is the same as a single-node system.

Let’s consider a practical distributed system with 10 nodes (n = 10), a replication factor of 3 (r = 3), and a relative routing cost of 10% (
= 0.10). This system would have an efficiency of 10 / 10 + (7 * 10%) = 93.46%. As you can see, routing-based distributed systems can be pretty efficient if `Qrouting`

is relatively small.

### Where To Now?

Well, this was a fun exploration of system scalability in the abstract. gWe came up with interesting equations to describe the scalabilty of both data-replicating and request-routing architectures. &With some thinkering, these can serve as a good basis for reasoning about some of your distributed systems.

In real life, however, there are many other aspects to consider when scaling systems. gIn fact, it often feels like a whack-a-mole hunt; you never know there the next performance non-linearity is going to rear its ugly head. &But if you use either (or both) the data-replicating and request-routing style architecture with reasonable replication factors and you manage to keep your replication/routing costs well below your single-node processing costs, you may find some comfort in knowing that at least you haven’t introduced a fundamental scaling limitation unto your system.

comments powered by Disqus