Performance Testing & Benchmarking
Info
Kubernetes Docs | Cloud Native Landscape | Kubernetes Secrets threat model | Managing Kubernetes without losing your cool
Full Suite Testingඞ
- Find latest Phoronix release
- Get Phoronix:
wget https://github.com/phoronix-test-suite/phoronix-test-suite/releases/download/v10.8.4/phoronix-test-suite-10.8.4.tar.gz - Unpack:
tar -xvzf phoronix-test-suite-10.8.4.tar.gz - Change directory:
cd phoronix-test-suite/ - Install dependencies:
dnf install php-cli php-xml php-json gd gd-develsudo apt-get install php-cli php-xml libgd-dev- Browse suites at openbenchmarking.org
- And run them with
sh phoronix-test-suite <ARGS>
Tests will be saved in ~/.phoronix-test-suite/test-results/*. Run sh phoronix-test-suite list-saved-results to list results and then view specific result with sh phoronix-test-suite show-result <RESULT NAME>.
Selected tests:
-
For CPU:
-
For memory:
Bash -
For disk:
Bash
Disk performance testing with FIOඞ
Flexible I/O tester docs fio output explained ArsTechnica fio recommended tests
Single 4KiB random write processඞ
This is a single process doing random 4K writes. This is where the pain really, really lives; it's basically the worst possible thing you can ask a disk to do. Where this happens most frequently in real life: copying home directories and dotfiles, manipulating email stuff, some database operations, source code trees.
| Bash | |
|---|---|
16 parallel 64KiB random write processesඞ
This time, we're creating 16 separate 256MB files (still totaling 4GB, when all put together) and we're issuing 64KB blocksized random write operations. We're doing it with sixteen separate processes running in parallel, and we're queuing up to 16 simultaneous asynchronous ops before we pause and wait for the OS to start acknowledging their receipt. This is a pretty decent approximation of a significantly busy system. It's not doing any one particularly nasty thing—like running a database engine or copying tons of dotfiles from a user's home directory—but it is coping with a bunch of applications doing moderately demanding stuff all at once.
This is also a pretty good, slightly pessimistic approximation of a busy, multi-user system like a NAS, which needs to handle multiple 1MB operations simultaneously for different users. If several people or processes are trying to read or write big files (photos, movies, whatever) at once, the OS tries to feed them all data simultaneously. This pretty quickly devolves down to a pattern of multiple random small block access. So in addition to "busy desktop with lots of apps," think "busy fileserver with several people actively using it."
| Bash | |
|---|---|
Single 1MiB random write processඞ
This is pretty close to the best-case scenario for a real-world system doing real-world things. No, it's not quite as fast as a single, truly contiguous write... but the 1MiB blocksize is large enough that it's quite close. Besides, if literally any other disk activity is requested simultaneously with a contiguous write, the "contiguous" write devolves to this level of performance pretty much instantly, so this is a much more realistic test of the upper end of storage performance on a typical system.
You'll see some kooky fluctuations on SSDs when doing this test. This is largely due to the SSD's firmware having better luck or worse luck at any given time, when it's trying to queue operations so that it can write across all physical media stripes cleanly at once. Rust disks will tend to provide a much more consistent, though typically lower, throughput across the run.
You can also see SSD performance fall off a cliff here if you exhaust an onboard write cache—TLC and QLC drives tend to have small write cache areas made of much faster MLC or SLC media. Once those get exhausted, the disk has to drop to writing directly to the much slower TLC/QLC media where the data eventually lands. This is the major difference between, for example, Samsung EVO and Pro SSDs—the EVOs have slow TLC media with a fast MLC cache, where the Pros use the higher-performance, higher-longevity MLC media throughout the entire SSD.
| Bash | |
|---|---|