Back-of-the-envelope calculations (BOTECs) are approximate calculations performed through simplified assumptions using math. These are rough calculations and might not be precise, but they can be a valuable tool to estimate resources in the early stages of a system design. BOTECs help us ignore the nitty-gritty details of the system (at least at the design level) and focus on more important aspects. To build and run any software system, we need the following resources:
Servers
Storage
For example, a service will need the following approximate resources to seamlessly handle the users' requests:
These calculations are based on the assumption about the workload/requirements of the system and the capacity of the servers/machines to be used in the system. We must estimate the above resources in the design stage of the system as they help serve the following purposes:
Feasibility assessment: The rough estimation of key resources, such as servers, storage, bandwidth, etc., helps a user assess the system’s feasibility if it’s viable or needs to be updated.
Performance analysis: The BOTECs help a designer to analyze the system’s performance by considering different factors like data size, bandwidth, number of requests handled by a server, etc.
Cost estimation and resource planning: The system designers can estimate costs and plan for the resources to be arranged for the system after analyzing BOTECs.
Trade-off analysis: The system designers can properly change the configuration to balance cost, performance, and resource utilization.
Quick resource estimation and high-level design overview also help in effective system design by reiterating these estimations to meet certain requirements.
There are many different servers, and each one is designed for specific jobs. These servers can do different things depending on how powerful they are, like how fast they can process information, how much memory they have, and how much data they can store. To accurately estimate the resources a system requires, it is crucial to carefully select the appropriate server type that aligns with the application’s or service’s demands. In the subsequent sections, we will delve deeper into these practical considerations, particularly estimation of the operation time.
The time taken by the central processing unit (CPU) to process a request depends directly on the clock rate. The CPU’s frequency determines the clock rate—the speed at which the CPU’s clock generates pulses. Each request is related to performing rigorous calculations, executing a query, or writing/reading data to/from memory. The time to process such requests depends on the number of clock cycles (cc) it takes for completion. For example, it takes one clock cycle to add two numbers,
Note: We'll use conventions like bn for billions, ms for milliseconds, and ns for nanoseconds.
Let’s assume we have a CPU with a frequency of
The time it takes to complete an operation, known as the operation time, is calculated by multiplying the number of CPU clock cycles required for the operation by the time taken per clock cycle. We can calculate the operation time as follows:
Though a real-time request might be related to combining multiple operations, we’ll begin by calculating clock cycles and then the time for specific operations to gain a better understanding. As we progress, we’ll gradually explore real-time examples.
Note: Instruction-level parallelism (ILP) is also possible in modern systems and can be achieved by techniques such as pipelining, superscalar execution, and out-of-order execution. Though ILP increases the
instruction per clock cycle (IPC) IPC is a metric used to measuring the efficiency of a processor to execute instructions. , in our case, we consider each clock cycle executes single instruction only. Instructions per clock cycle (IPC) is a metric used to measuring the efficiency of a processor to execute instructions.
Let’s estimate the time taken by different operations in the subsequent sections.
Suppose a request needs the server to encrypt
So, the time taken to complete the operation is:
Based on the above assumptions, a processor takes
The number of clock cycles to access memory depends on the memory access speed. Reading or writing 1 byte of data to/from memory typically takes
So, the time taken to complete the operation is:
Based on the above assumptions, it takes
A database would take approximately
Parsing and optimizing queries
Retrieving necessary data to memory
Retrieving matching records and filtering it
Returning results
So, the time to execute a query is as follows:
Based on the above assumptions, it takes
Note: In real-world scenarios, the time taken to execute a database query can vary significantly based on various factors, such as the complexity of the query, hardware performance, database optimizations, and the size of the data being processed. It's important to benchmark and profile the system to get more accurate time measurements.
So far, we have estimated the time to process requests with specific operations. Now, let’s consider a real-time scenario to evaluate the time and, hence, the capacity of the server to process such requests:
Let's estimate the time for a request with
of data to be retrieved from the database and stored in memory after encrypting using advanced encryption standards (AES); we need to estimate time and processing capacity of the server.
We must consider the time it takes to query the data, encrypt it using the AES, and store it in the memory. From the above calculations, the time taken for each operation is:
So, putting the values calculated earlier:
Based on the above assumptions, it takes
We estimated the time it takes to process a single clock cycle considering a CPU with a frequency of
Free Resources