# Chapter 2: Methodologies

The Learning objectives of this chapter:

* Understand key performance metrics: latency, utilization, and saturation
* Develop a sense for the scale of measured time, down to nanoseconds
* Learn tuning trade-offs, targets, and when to stop analysis
* Identify problems of workload versus architecture
* Consider resource versus workload analysis
* Follow different performance methodologies, including: the USE method, workload characterization, latency analysis, static performance tuning, and performance mantras
* Understand the basics of statistics and queueing theory

## Terminology

* **IOPS**: Input/output operations per second is a measure of the rate of data transfer operations. For disk I/O, IPOS refers to reads and writes per second.
* **Throughput**: The rate of work performed. It can refer to the data rate (bytes per second or bits per second), or the operation rate (operations per second or transactions per second)
* **Response time**: The time for an operation to complete.
* **Latency**: A measure of time an operation spends waiting to be serviced. It also refers to the entire time for an operation.
* **Utilization**: For resources that service request, utilization is a measure of how busy a resource is, based on how much time in a given interval it was actively performing work. (disk I/O, CPU, Memory, storage etc)
* **Saturation**: The degree to which a resource has queued work it cannot service.
* **Bottleneck**: it is a resource that limits the performance of the system.
* **Workload**: The input to the system or the load applied is the workload. For a database, the workload consists of the database queries and commmands send by the clients.
* **Cache**: A fast storage area that can duplicate or buffer a imited amount of data, to avoid communicating directly with a slower tier of storage, thereby improving performance.

## Models

### System Under Test

![2.1 Block diagram of system uder test](https://388701358-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LmDY11BLFD0Iupj9U9t%2Fuploads%2Fgit-blob-7af0fc0c707f14ddbb4af9b0de391b4b0997e05d%2Ffigure_2.1.png?alt=media)

### Queueing System

![2.2 Simple queueing model](https://388701358-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LmDY11BLFD0Iupj9U9t%2Fuploads%2Fgit-blob-5bd67abc4b3ec4bafaf95266be5836edeb0aca12%2Ffigure_2.2.png?alt=media)

## Concepts

### Latency

![2.3 Network connection latency](https://388701358-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LmDY11BLFD0Iupj9U9t%2Fuploads%2Fgit-blob-99723bed734f199277f6ccacacecf2954010131d%2Ffigure_2.3.png?alt=media)

The latency is the time spent waiting before an operation is performed.

### Time Scales

![Table 2.2 Example time scale of system latencies](https://388701358-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LmDY11BLFD0Iupj9U9t%2Fuploads%2Fgit-blob-3c64f816fd2ce881ff5ab0340ad69f1a40c8bdf4%2Ftable_2.2.png?alt=media)

### Trade-Offs

The good/fast/cheap "pick two" trade-off. ![Trade-offs: pick two](https://388701358-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LmDY11BLFD0Iupj9U9t%2Fuploads%2Fgit-blob-34c7b07ba8e01cac11ee061753e0d5c20075403e%2Ffiture_2.4.png?alt=media)

A common trade-off in performance tuning is the one between CPU and memory, as memory can be used to cache results, reducing CPU usage.

Tunable parameters often come with trade-offs. Examoles:

* File system record size (or block size):
  * Small reocrd sizes, close to the application I/O size, will perform better for random I/O workloads and make more efficient use of the file system cache while the application is running.
  * Large record sizes will improve streaming workloads, including file system backups.
* Network buffer size:
  * Small buffer sizes will reduce the memory overhead per connection, helping the system scale.
  * Large sizes will improve network throughput.

### Tunning Efforts