Bottleneck Identification Language Exercises

1 / 5

A performance engineer says: "This service is CPU-bound."

Which observation in profiling output would confirm a CPU-bound diagnosis?

A CPU-bound service is constrained by processing power. Profiling shows: CPU near 100%, wall time ≈ CPU time (no waiting), adding cores scales throughput. The fix is algorithm optimisation or horizontal scaling with more vCPUs.

Bottleneck type	CPU util	Wall ≈ CPU?	Fix direction
CPU-bound	~100%	Yes	Optimise algorithm, add cores
I/O-bound	Low	No — wall ≫ CPU	Async I/O, caching, read replicas
Memory-bound	Spiky (GC)	Varies	Increase heap, fix leaks, tune GC

2 / 5

A profiler confirms: "The service is I/O-bound — 70% of request time is waiting for database responses."

Which architectural pattern best addresses I/O-bound bottlenecks?

For I/O-bound services: async I/O prevents threads from blocking while waiting; connection pooling prevents connection exhaustion; read replicas distribute read load; caching eliminates redundant I/O entirely. Adding CPU cores doesn't help — the CPU is mostly idle waiting.

I/O-bound fix	How it helps
Async / non-blocking I/O	Thread is not blocked during I/O wait — can serve other requests
Connection pool tuning	Prevents connection starvation under high concurrency
Read replica	Distributes read traffic across multiple DB instances
Cache hit ratio	Higher cache hit = fewer DB calls = lower latency

3 / 5

A monitoring dashboard shows CPU usage spikes every 30–60 seconds coinciding with latency spikes. A profiler shows: "high memory pressure."

What does "memory pressure" mean and what symptoms does it cause?

Memory pressure = GC runs too frequently because the heap is running low. Each major (stop-the-world) GC cycle pauses all threads, causing latency spikes and CPU spikes in GC threads. If unresolved, the heap fills completely → OutOfMemoryError.

Symptom	Root cause
Latency spikes every N seconds	Stop-the-world GC pauses
CPU % in GC threads high	GC overhead — spending >10% of time in GC
OOM errors in logs	Heap exhausted — memory leak or heap too small

Key vocabulary: heap pressure, GC overhead, heap dump analysis, OOM (Out of Memory).

4 / 5

A monitoring alert fires: "Thread pool saturated — all 200 threads are active with 3,000 requests queued."

What happens to incoming requests when a thread pool reaches saturation?

Thread pool saturation: when all threads are busy, new requests go to the work queue. If the queue fills too, requests are rejected (Java: RejectedExecutionException, HTTP: 503). The fix is: reduce per-request blocking time (async I/O) or tune pool size.

Term	Meaning
thread pool exhaustion	All threads are busy — no capacity to start new requests immediately
work queue depth	Number of requests waiting to be picked up by a thread — high depth = high latency
back pressure	Signal propagated upstream that the service cannot accept more requests
thread pool sizing	Setting core/max threads based on concurrency requirements and I/O ratio

5 / 5

A profiler identifies that lock contention is the bottleneck — 30 threads are waiting for the same global lock on the UserCache.

When presenting this finding to an engineering manager, which explanation is most effective?

Effective bottleneck communication to management: specific resource (UserCache), measured impact (40% of p99 latency), root cause (single global lock blocks reads), proposed fix and expected outcome (ReadWriteLock allows concurrent reads).

Term	Meaning
lock contention	Multiple threads competing to acquire the same lock — only one wins, others wait
critical section	The code block protected by a lock — should be as small as possible
ReadWriteLock	Allows concurrent reads (no contention) but exclusive write access
lock-free data structure	Uses atomic operations instead of locks — eliminates contention entirely