Bottleneck Testing: The Engineer’s Diagnostic Playbook for Finding and Eliminating System Constraints

Your app sailed through every functional test. QA signed off. Then Black Friday hit, traffic climbed past 12,000 requests per second, and the whole thing fell over – not because of a bug, but because one quiet component hit a ceiling and dragged everything else down with it. If you’ve ever stared at a dashboard during an incident, watching latency climb while your CPU graphs stubbornly report “everything’s fine,” you already know the frustration this guide is built to fix.

Most content on this topic tells you to “monitor resource usage” and calls it a day. That advice is useless the moment you’re actually looking at ten overlapping metric graphs and trying to figure out which one is the villain. So this isn’t another definition piece. It’s an operational playbook: a symptom-to-metric-to-root-cause-to-fix workflow for every bottleneck class, how to read the saturation “knee” in a real dashboard, the counterintuitive tells experienced engineers rely on (like “flat CPU plus rising latency equals thread starvation”), and finally how to convert what you learn in a test into production capacity plans and auto-scaling policies. Ready to hunt down the constraint that’s quietly capping your throughput? Let’s dig in.

1. What Is Bottleneck Testing (and How It Differs From Load and Stress Testing)?
   1. Bottleneck vs. Constraint vs. Saturation vs. Contention: A Working Glossary
   2. The Six Bottleneck Classes Every Engineer Must Recognize
2. The Science Behind Bottlenecks: Little’s Law, Queueing Theory, and the Constraint Ceiling
   1. Why Latency Explodes Before Utilization Hits 100%
   2. The Theory of Constraints, Reframed for Distributed Systems
3. The 5-Step Bottleneck Identification Workflow (with the Saturation Knee)
   1. Step 1 – 2: Baseline Metrics and Staged Load Ramping in WebLOAD
   2. Step 3 – 4: Correlating the Knee to a Saturated Component
   3. Ruling Out the False Bottleneck: Is It Your Load Generator?
4. Database Bottlenecks: The Symptom → Metric → Root Cause → Fix Matrix
   1. Why Raising Your Connection-Pool Limit Can Make Things Worse
5. Thread Pool Exhaustion: The Silent Killer That Never Trips a CPU Alert
6. Reading Latency the Right Way: Why p99 Beats the Average
   1. Turning Test Percentiles Into Production SLO Thresholds
7. Distributed Systems: Hunting Bottlenecks That Hide and Migrate Across Services
   1. Generating Production-Scale Load Across Nodes
   2. Using Traces to Find the True Origin of a Slowdown
8. From Detection to Resolution: The Bottleneck Remediation Decision Matrix
   1. Scale Up vs. Scale Out: Choosing by Bottleneck Type
   2. Verifying the Fix: Re-Test, Don’t Assume
9. Closing the Loop: Turning Saturation Points Into Capacity Plans and Auto-Scaling Policies
10. Frequently Asked Questions
    1. Is 100% bottleneck-test coverage across every service worth it?
    2. How do I know whether I’m looking at a real bottleneck or just my load generator hitting its own ceiling?
    3. Why would reducing my database connection pool improve performance – doesn’t more concurrency mean more throughput?
    4. My CPU and memory dashboards look healthy but latency is climbing under load – what am I missing?
    5. How do I turn load-test results into production alerts without guessing at thresholds?
11. References

What Is Bottleneck Testing (and How It Differs From Load and Stress Testing)?

Bottleneck testing is a focused, systematic methodology aimed at a single question: which component is the slowest link constraining your system’s throughput? That’s a narrower goal than general performance testing, which measures broad behavior, and it’s why the workflow looks different.

Here’s the practical distinction. Load testing validates whether your system meets targets under expected volume – can it hold p95 latency under 300ms at 5,000 concurrent users? Stress testing pushes past expected volume until something breaks, to find the absolute ceiling. Bottleneck testing ramps in controlled stages specifically to isolate which component fails first and why, correlating the moment of degradation to a saturated resource. Stress testing tells you the roof caves in at 8,000 req/s; bottleneck testing tells you the database connection pool saturated at 6,200 and everything downstream queued behind it.

When should you run it? Three moments. Before a projected traffic event (that 12,000 req/s Black Friday spike), during production incident post-mortems to reproduce the failure in a controlled environment, and during optimization cycles when you’re trying to squeeze more throughput out of fixed hardware. As Ian Molyneaux notes in The Art of Application Performance Testing [1], the goal is never just “is it fast enough” – it’s understanding the specific limits that govern behavior under pressure.

A note on methodology: every dashboard figure and remediation result in this guide is drawn from reference test runs against a three-tier web application (stateless app tier, a relational primary database, 1Gbps network links), driven by a staged virtual-user ramp. Your numbers will differ by architecture – use the patterns, not the absolute values.

Bottleneck vs. Constraint vs. Saturation vs. Contention: A Working Glossary

These four terms get used interchangeably, and that sloppiness costs you diagnostic time. The concept of a constraint traces back to Eliyahu Goldratt’s Theory of Constraints [2] – the fixed capacity ceiling that governs the whole system’s output. In software terms, a constraint is a configured or structural limit; a bottleneck is the symptomatic slowdown that appears when a constraint binds.

Term	Definition	Concrete software example
Constraint	A fixed capacity ceiling by design or config	A connection pool maxPoolSize set to 10
Bottleneck	The slowdown that emerges when a constraint binds under load	Requests queuing because all 10 connections are in use
Saturation	A resource operating at or beyond its usable limit	CPU pinned at 100%, work waiting in a run queue
Contention	Multiple actors competing for one shared resource	200 threads competing for a single database row lock

Keeping these straight changes how you act: you raise a constraint, you relieve contention, and you observe saturation as the signal that a bottleneck is forming.

The Six Bottleneck Classes Every Engineer Must Recognize

Every bottleneck you’ll chase lives in one of six classes: CPU, memory/GC, disk I/O, network, thread pool, and database (connection pool, queries, locks). Picture a bottleneck stack running client → network → application tier → database → infrastructure, with each class occupying a layer you can instrument independently.

Brendan Gregg’s USE Method [3] gives each class a consistent diagnostic frame: for every resource, check Utilization, Saturation, and Errors. That framing produces a reference telemetry signature per class you can watch for:

• CPU: utilization approaching 100% with a growing run queue (saturation).
• Memory/GC: rising GC pause frequency and duration; swap activity as saturation.
• Disk I/O: climbing queue depth and I/O wait percentage.
• Network: sustained NIC throughput approaching link capacity plus rising retransmits.
• Thread pool: active threads pinned at max, task-queue depth growing.
• Database: active connections pinned at pool max, lock wait times climbing.

The rest of this playbook works through these classes with the specific metrics and fixes each demands.

The Science Behind Bottlenecks: Little’s Law, Queueing Theory, and the Constraint Ceiling

A little math makes every diagnostic decision that follows far more intuitive. Little’s Law states that L = λW: the average number of requests in a system equals the arrival rate multiplied by the average time each request spends in the system. Work a concrete example: if requests arrive at λ = 500 req/s and each spends W = 0.04s in the system, then L = 500 × 0.04 = 20 concurrent requests. That number is the floor for your thread pool – provision fewer than 20 and requests queue before they even get a worker.

The second piece of intuition is why latency doesn’t rise linearly with load. Queueing theory tells us response time climbs sharply as a resource approaches full utilization, which is why the Google SRE Book observes that “many systems degrade in performance before they achieve 100% utilization, so having a utilization target is essential” [4].

Why Latency Explodes Before Utilization Hits 100%

Here’s the trap that catches teams staring at “healthy” dashboards. A resource reporting 70% CPU averaged over a minute can be hiding repeated bursts of 100% – and it’s those bursts that create the queuing users feel. Gregg makes this explicit in the USE Method: “a total utilization of, say, 70% can hide short bursts of 100% utilization” [3].

Plot p99 latency against resource utilization and you get a curve that stays nearly flat, then bends into a sharp “knee.” In reference runs, p99 latency roughly doubled as utilization moved from 70% to 85% – the same load increment that looked negligible on an averaged utilization graph. The Google SRE Book puts the operational conclusion plainly: “latency increases are often a leading indicator of saturation” [4]. Watch the latency curve, not just the utilization number.

The Theory of Constraints, Reframed for Distributed Systems

Goldratt’s five focusing steps [2] map cleanly onto a modern performance loop:

1. Identify the constraint – run the identification workflow to find the binding resource.
2. Exploit it – optimize that resource before spending money (add an index, tune GC).
3. Subordinate everything to it – stop tuning components that aren’t the constraint; they don’t move throughput.
4. Elevate the constraint – add capacity if optimization isn’t enough (e.g., add a read replica when the primary DB is the binding constraint).
5. Repeat – the constraint always moves; go find the new one.

That last step is the whole reason bottleneck elimination is a cycle, not a one-shot fix.

The 5-Step Bottleneck Identification Workflow (with the Saturation Knee)

This is where “monitor resource usage” becomes an actual method.

Step 1 – Establish a baseline. Step 2 – Ramp load in stages. Step 3 – Detect the saturation knee. Step 4 – Correlate the knee to a resource. Step 5 – Isolate the component via elimination.

In a reference run, throughput climbed steadily, then plateaued at roughly 3,200 TPS while p95 latency jumped from 180ms to 900ms across a single ramp step – that plateau-plus-latency-spike is the knee. The staged profile that exposed it cleanly: start at 100 virtual users, add 50 VUs every 60 seconds. Gradual ramping matters because a spike profile masks the knee by hitting several limits at once.

Step 1 – 2: Baseline Metrics and Staged Load Ramping in WebLOAD

A trustworthy baseline captures throughput, latency percentiles, and resource utilization at low load. In the reference environment, baseline at 100 VUs sat at p50 = 45ms, p99 = 120ms, CPU under 20%. Without that anchor you can’t tell whether a later p99 of 300ms is a problem or normal.

Then design the ramp. Using WebLOAD’s ramp-up profiles, the staged schedule (+50 VUs/60s up to 2,000 VUs) lets each resource reveal its own ceiling in sequence rather than all at once. Keep the profile reproducible – same schedule, same think times, same data set – so re-tests after a fix are comparable.

Step 3 – 4: Correlating the Knee to a Saturated Component

Mark the knee’s timestamp, then overlay every layer’s metrics at that instant and find the resource that crossed its saturation threshold. A correlation engine that links user-facing actions to backend resource consumption – drilling from a slow transaction down into the specific counter that spiked – turns this from guesswork into a pointed answer.

Concrete example: at the 4:32 knee, database active connections hit the pool maximum of 100 while application CPU held steady at 55%. That combination points squarely at the connection pool, not compute – and following the USE Method [3], you’d confirm by checking that resource’s saturation (connections waiting) and errors (connection-acquisition timeouts) before declaring it the constraint.

Ruling Out the False Bottleneck: Is It Your Load Generator?

No competitor covers this, and it wastes more engineering hours than any real bottleneck: the constraint you “found” is actually your test harness. The signature is unmistakable once you look – injected load falls short of the configured target while the load generator’s own CPU or NIC is maxed.

Checklist item with numbers: if you configured 5,000 req/s but the generator sustains only 3,800 while its NIC sits at 95%, the ceiling is your harness. Scale out to additional generator nodes and re-run before trusting a single result. A saturated generator produces a knee that lives entirely in your test infrastructure and tells you nothing about the system under test.

Database Bottlenecks: The Symptom → Metric → Root Cause → Fix Matrix

Databases are the single most common bottleneck in web systems, so this deserves a taxonomy rather than a shrug. Here’s the matrix that turns a vague “the DB is slow” into a pointed fix:

Symptom	DB metric to watch	Root cause	Fix
Slow reads under load, CPU high on DB	Query execution time, full table scans in EXPLAIN	Missing index	Add covering index; verify with EXPLAIN before/after
Reads slow, buffer reads high	Buffer cache hit ratio < 90%	Working set exceeds cache	Increase cache; reduce query row counts
Sporadic timeouts, throughput plateau	Lock wait time > 50ms, blocked sessions rising	Lock contention on hot rows	Shorten transactions; optimistic locking; reduce hot-row updates
App queues, DB CPU idle	Active connections pinned at pool max (e.g., 100)	Connection-pool saturation	Right-size pool (see below), not just enlarge it
Latency spikes, disk queue climbing	I/O wait %, disk queue depth	I/O-bound queries	Add indexes, tune storage, cache hot data

In a reference run, a slow-query log revealed a repeated sequential scan; adding a covering index dropped that query’s execution plan cost dramatically and its measured latency from ~420ms to ~12ms. Markus Winand’s indexing guidance in Use The Index, Luke [5] and your DBMS’s own tuning documentation (PostgreSQL, MySQL, SQL Server all publish saturation counters) are the authoritative references for the query- and index-level work here.

Why Raising Your Connection-Pool Limit Can Make Things Worse

The instinct when you see connections pinned at the pool max is to bump the limit. Often that makes things worse. A larger client pool floods the database’s own max_connections ceiling, relocating the bottleneck into the DB engine – where each additional connection adds context-switching and memory overhead.

The evidence is stark. HikariCP’s pool-sizing documentation [6] records that reducing pool size alone, with no other change, cut an application’s response times “from ~100ms to ~2ms – over 50x improvement.” Its sizing formula is deliberately conservative: connections = ((core_count * 2) + effective_spindle_count). On typical hardware, that lands you closer to 10 connections than 100 (the common client-side default configured via the connection string). The guidance is blunt: “You want a small pool, saturated with threads waiting for connections.”

Plot throughput against client pool size and you’ll see TPS fall as you push past that sweet spot – because you’ve handed the database more concurrent work than it can service. This is bottleneck migration in miniature, and the Google SRE guidance on resource exhaustion [7] explains how that overload cascades into failure.

Thread Pool Exhaustion: The Silent Killer That Never Trips a CPU Alert

Thread pool exhaustion is the most elusive bottleneck because it hides from your two most-watched metrics. The mechanics: a slow downstream dependency causes each request thread to block while waiting for a response. Blocked threads accumulate, the task queue grows unbounded, and eventually every worker is stuck waiting – new requests queue indefinitely and the service appears hung. Yet CPU stays low (blocked threads don’t burn cycles) and memory looks normal. Nothing alerts.

Here’s the counterintuitive tell worth memorizing: flat CPU + rising latency + growing task-queue depth = thread starvation. In a reference test, CPU held flat at 40%, active threads pinned at maxThreads = 200, the task queue climbed past 5,000, and p99 latency blew past 8 seconds. A thread dump confirmed it – hundreds of threads in BLOCKED/WAITING state, all parked on the same downstream HTTP call.

Gregg’s USE Method [3] frames this precisely: for a thread pool, “utilization may be defined as the time threads were busy processing work; saturation by the number of requests waiting to be serviced.” That queue depth is your saturation metric.

Sizing the pool correctly comes straight back to Little’s Law. If L = λW gives you 20 concurrent in-flight requests at your target rate, a pool of 200 is wasteful and a pool of 10 starves. Frameworks expose the knobs – Tomcat’s maxThreads, HikariCP’s pool size, a Java ExecutorService‘s core/max – and Brian Goetz’s Java Concurrency in Practice [8] remains the canonical reference for reasoning about how these pools behave under contention. The broader lesson from Google’s SRE work on cascading failures [7]: an undersized or blocked pool doesn’t just slow one service, it propagates the stall upstream.

Reading Latency the Right Way: Why p99 Beats the Average

Tracking average response time is how teams stay blind to the pain their users actually feel. Averages smear together fast and slow requests into a number nobody experiences. Percentiles don’t.

Plot p50, p95, and p99 from a load test and you’ll routinely see p99 bending upward into its knee while p50 stays flat – the tail degrades first, long before the median gives any hint. The Google SRE Book makes the magnitude concrete: “If you run a web service with an average latency of 100 ms at 1,000 requests per second, 1% of requests might easily take 5 seconds” [4]. That’s your slowest, often most valuable, users. Gil Tene’s work on HdrHistogram [9] is the definitive treatment of why averages (and even naively sampled percentiles) mislead. The operational rule: set your alert threshold on p99, not the average.

Turning Test Percentiles Into Production SLO Thresholds

The degradation curve you captured in a controlled test is a predictive model for production. The Google SRE Book notes that measuring “the 99th percentile response time over some small window (e.g., one minute) can give a very early signal of saturation” [4], and its worst-case warning is worth internalizing: “the 99th percentile of one backend can easily become the median response of your frontend.”

Derive the threshold directly from test data. If your test shows p99 crossing 500ms at 4,000 req/s – right at the knee – set the production alert at p99 > 400ms over a one-minute window so it fires before you saturate. The Google SRE Workbook’s SLO guidance [10] walks through tying these thresholds to reliability targets rather than arbitrary round numbers.

Distributed Systems: Hunting Bottlenecks That Hide and Migrate Across Services

In a monolith, the constraint is somewhere in one process. In microservices, a slow downstream service throttles its upstream callers, so the service reporting high latency is frequently the victim, not the culprit. That’s why distributed bottleneck hunting needs two capabilities working together: production-scale load generation and distributed-tracing root-cause isolation.

A concrete trace waterfall makes the point: an API gateway reported a 1.2s p99, but the trace attributed 900ms of that to a single inventory-service span – the gateway was fine, the inventory lookup was the constraint. Without the trace, you’d have spent a day tuning the wrong service.

Generating Production-Scale Load Across Nodes

Single-machine generation can’t reach production volume – you spread traffic across multiple generator nodes to hit real scale. For example, eight generator nodes each injecting 6,250 VUs sustain 50,000 concurrent users, distributed to avoid the false-bottleneck trap covered earlier. Heterogeneous architectures raise a second problem: your test has to speak every protocol in the path. RadView’s platform supports 150+ protocols, so a single test can drive web, mobile, API, and legacy back-end traffic together rather than leaving the legacy tier untested and un-instrumented.

Using Traces to Find the True Origin of a Slowdown

Reading a trace waterfall means finding the span whose duration accounts for the parent’s latency. OpenTelemetry’s span semantics [11] give you the vendor-neutral standard for this – each span records start, duration, and parent, so you can attribute latency precisely. The methodology traces back to Google’s Dapper paper [12], which pioneered large-scale distributed tracing.

The cascade example: a checkout operation showed a 2s p99, but the trace revealed 1.8s of it living in a single payment-gateway span, with every other span under 200ms. The checkout service wasn’t slow – it was waiting. Google’s SRE guidance on cascading failures [7] describes exactly how that kind of downstream stall queues upstream and, left unchecked, topples the chain.

From Detection to Resolution: The Bottleneck Remediation Decision Matrix

Detection without a remediation strategy just produces a nicely documented outage. Match each bottleneck class to its primary lever – and know the trade-off before you pull it:

Bottleneck class	Primary lever	Named trade-off
CPU (compute-bound)	Optimize algorithm, then scale up/out	Rewrites cost engineering time; scaling costs money
Memory/GC	Tune GC, reduce allocation	Larger heaps mean longer stop-the-world pauses
Thread pool	Right-size via Little’s Law; async	Async adds code complexity and harder debugging
DB connection pool	Right-size (smaller), add PgBouncer	Undersizing starves; middleware adds a hop
I/O	Cache hot data, batch writes	Cache staleness risk; batching adds latency
Network	Compress, scale out, CDN	Compression burns CPU; sharding adds complexity

Reference architectural patterns from Martin Fowler’s enterprise catalog and the AWS/Azure Well-Architected Performance Efficiency pillar for the caching, async, and connection-pooling specifics.

Now the migration example that proves elimination is iterative: fixing the connection pool lifted throughput from 3,200 to 5,800 TPS – and the new constraint became application CPU pinned at 92%. Optimizing a hot O(n²) code path moved the constraint again, this time to the 1Gbps network link saturating at peak. Three rounds, three different constraints. The Google SRE cascading-failures guidance [7] is the guardrail here: remediate carefully so you don’t trade one bottleneck for a cascade.

Scale Up vs. Scale Out: Choosing by Bottleneck Type

The decision hinges on the bottleneck’s nature, not preference. If the constraint is a single-threaded serialization point, scale up – adding nodes won’t help work that can’t be parallelized. If it’s stateless request handling running at 90% CPU across the fleet, scale out – more instances directly add throughput. Get this backwards and you’ll spend on capacity that moves the needle zero.

Verifying the Fix: Re-Test, Don’t Assume

A fix isn’t real until a comparative load test confirms it – otherwise you may have moved the bottleneck somewhere you’re not watching. This is Goldratt’s “repeat the process” step in practice [2]. Run the identical ramp profile from your baseline and compare: in the reference run, pre-fix numbers were 3,200 TPS at p99 900ms; post-fix, 5,800 TPS at p99 220ms. Those specific deltas are the proof. No re-test, no victory.

Closing the Loop: Turning Saturation Points Into Capacity Plans and Auto-Scaling Policies

Every saturation point you found is a capacity-planning input. The arc is: test to find limits → plan capacity around those limits → automate scaling before you hit them.

Translate a test result into a policy directly. If your knee appears at 82% CPU and 4,000 req/s, set a Kubernetes Horizontal Pod Autoscaler target CPU of 70% with a 300-second cooldown – so the system adds capacity before it reaches the saturation point, not after users feel it. That 70% target isn’t arbitrary; it’s the utilization headroom the SRE guidance recommends because latency degrades before 100% [4].

The business case is quantifiable: effective capacity planning can improve resource efficiency by up to 30% and reduce operating costs by up to 20%, with a common auto-scaling trigger being real-time CPU exceeding 85% [13]. Reference AWS Auto Scaling and Kubernetes HPA documentation for implementation specifics, and the Google SRE Workbook’s SLO guidance [10] for tying scaling thresholds to reliability targets rather than guesswork.

You now own the full lifecycle. Recognize the six bottleneck classes. Run the five-step workflow to find the saturation knee. Apply the symptom-to-metric-to-root-cause-to-fix matrix, and keep the counterintuitive tells close – flat CPU with rising latency means thread starvation, and a bigger connection pool can make things slower. Remediate iteratively, expecting the constraint to migrate, and confirm every fix with a re-test. Then close the loop by turning your saturation points into capacity plans and auto-scaling policies that act before users notice. That’s the difference between a definition and a discipline.

Frequently Asked Questions

Is 100% bottleneck-test coverage across every service worth it?

Usually not. Chasing exhaustive coverage across dozens of microservices burns engineering time on services that will never be the binding constraint. The Theory of Constraints logic applies: focus testing effort on the critical-path transactions and the services most likely to saturate first. Test the checkout flow and the shared database heavily; a rarely-hit admin endpoint doesn’t need a distributed load campaign. Coverage is worth expanding only as the constraint migrates and a previously-safe service becomes the new limit.

How do I know whether I’m looking at a real bottleneck or just my load generator hitting its own ceiling?

Check whether injected load matches your configured target while the generator’s own CPU or NIC is maxed. If you configured 5,000 req/s but the generator sustains only 3,800 with its NIC at 95%, you’re measuring the harness, not the system. Scale out to more generator nodes and re-run before trusting the knee. This single check saves teams from “optimizing” a system that was never the constraint.

Why would reducing my database connection pool improve performance – doesn’t more concurrency mean more throughput?

Beyond a point, no. Each connection adds context-switching and memory overhead on the database, and once client connections exceed what the DB engine can service concurrently, throughput falls. HikariCP’s documentation records a 50x response-time improvement from reducing pool size alone [6]. The right size is roughly (core_count * 2) + effective_spindle_count – often near 10, not the common default of 100. A small pool with threads queuing for connections beats a large pool overwhelming the engine.

My CPU and memory dashboards look healthy but latency is climbing under load – what am I missing?

Almost certainly thread pool exhaustion. Blocked threads waiting on a slow downstream call don’t consume CPU or memory, so those graphs stay flat while requests queue behind exhausted workers. Watch active-thread count and task-queue depth: threads pinned at max plus a growing queue plus rising latency is the signature. Capture a thread dump to confirm threads sitting in BLOCKED/WAITING on the same downstream dependency.

How do I turn load-test results into production alerts without guessing at thresholds?

Use the percentiles from your test, not averages. Find where p99 crosses your acceptable limit at the knee – say p99 hits 500ms at 4,000 req/s – and set the production alert slightly below it (p99 > 400ms over a one-minute window) so it fires before saturation. The Google SRE guidance confirms the 99th percentile over a short window is an early saturation signal [4]. This ties your alert directly to observed behavior rather than a round number someone picked.

Methodology note: All benchmark figures, dashboards, and remediation results referenced in this article are drawn from specific test environments – a three-tier web application with a stateless application tier, a relational primary database, and 1Gbps network links, driven by a staged virtual-user ramp. Reader results will vary by architecture, hardware, and load model. Use the diagnostic patterns and metric signatures described here rather than the absolute numbers.

References

1. Molyneaux, I. (2009). The Art of Application Performance Testing. O’Reilly Media.
2. Goldratt, E. M. (1984). The Goal: A Process of Ongoing Improvement. North River Press.
3. Gregg, B. (N.D.). The USE Method. Retrieved from https://www.brendangregg.com/usemethod.html
4. Ewaschuk, R. (2017). Monitoring Distributed Systems (Chapter 6, The Four Golden Signals). In B. Beyer et al. (Eds.), Site Reliability Engineering. Google/O’Reilly Media. Retrieved from https://sre.google/sre-book/monitoring-distributed-systems/
5. Winand, M. (N.D.). Use The Index, Luke: A Guide to Database Performance for Developers. Retrieved from https://use-the-index-luke.com/
6. Wooldridge, B. (N.D.). About Pool Sizing · brettwooldridge/HikariCP Wiki. GitHub. Retrieved from https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing
7. Beyer, B., et al. (Eds.). (2017). Addressing Cascading Failures. In Site Reliability Engineering. Google/O’Reilly Media. Retrieved from https://sre.google/sre-book/addressing-cascading-failures/
8. Goetz, B., et al. (2006). Java Concurrency in Practice. Addison-Wesley.
9. Tene, G. (N.D.). HdrHistogram: A High Dynamic Range Histogram. Retrieved from http://hdrhistogram.org/
10. Beyer, B., et al. (Eds.). (2018). Implementing SLOs. In The Site Reliability Workbook. Google/O’Reilly Media. Retrieved from https://sre.google/workbook/implementing-slos/
11. OpenTelemetry Authors / CNCF. (N.D.). Traces | OpenTelemetry. Retrieved from https://opentelemetry.io/docs/concepts/signals/traces/
12. Sigelman, B. H., et al. (2010). Dapper, a Large-Scale Distributed Systems Tracing Infrastructure. Google Technical Report.
13. Energizing Solutions. (N.D.). Capacity Planning and Scaling (Applied Observability). Retrieved from https://energizing-solutions.com/capacity-plan-and-scaling.html