Vocabulary for identifying and communicating performance bottlenecks: CPU-bound, I/O-bound, memory pressure, GC pauses. Advanced
0 / 13 completed
1 / 13
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 / 13
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 / 13
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.
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 / 13
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
6 / 13
Sarah from the front-end team just posted this comment on your PR:
'I'm seeing a noticeable delay when submitting the form. Can you investigate?' Considering the context of a high-traffic e-commerce application, what's the MOST likely cause of this delay based on common bottleneck identification techniques?
While all options could *potentially* contribute to delays, high CPU utilization is frequently the first thing to investigate when a user reports sluggishness. A spike in CPU often correlates with long-running operations or inefficient code execution. The other options are less likely primary causes without additional evidence – database indexing problems would typically manifest as slow queries, network latency can be intermittent and complex to diagnose, and overly complex forms may have usability issues but not directly cause performance delays.
7 / 13
Ben, a senior developer, sends you this Slack message:
'The API response times are consistently above 500ms. The logs show a lot of calls to the external payment gateway service. We need to reduce latency.' Which of the following strategies would MOST directly address this bottleneck?
While caching and optimizing code are good practices, simply increasing the number of parallel requests to an external service (like a payment gateway) is *highly* likely to exacerbate the problem. External services often have rate limits or aren't designed for massive concurrency. The core issue here is the response time itself – the best immediate solution is to reduce the load on the bottlenecked service, which can be achieved by optimizing requests to it.
8 / 13
You've identified a significant bottleneck in your application: high latency during user authentication. The monitoring system shows consistently elevated CPU usage on the authentication server and an increase in the number of threads contending for access to a shared lock used for verifying credentials. What does 'thread contention' signify, and how does it contribute to this authentication bottleneck?
Thread contention occurs when multiple threads attempt to access or modify shared resources (like the credential verification logic) concurrently. This leads to threads blocking each other while waiting for exclusive access, dramatically increasing latency and reducing throughput. It's a classic synchronization problem – the more threads competing for the same resource, the longer it takes to complete any operation.
9 / 13
David from the DevOps team sends you this message:
'We're seeing a high number of '502 Bad Gateway' errors. The monitoring shows increased latency to our third-party analytics service. Initial investigations suggest it might be overloaded.' What does '502 Bad Gateway' typically indicate in this scenario, and what immediate action should you recommend?
A '502 Bad Gateway' error signifies that the application server successfully contacted the analytics service but didn't receive a valid response. This often points to an issue *on the other side* of the connection – the analytics service itself is unavailable or overloaded. Choosing 'Insufficient capacity' is incorrect as it suggests a problem with your own system, while options C and D are possible causes but less directly indicated by the error code.
10 / 13
Maria, a QA engineer, flags a performance issue in her testing:
'The new feature is incredibly slow when processing large datasets. The response times are consistently exceeding 15 seconds for a single operation.' Considering this feedback, what's the MOST likely bottleneck related to data processing?
While network latency, memory allocation, and excessive logging *could* contribute, the description of 'consistently exceeding 15 seconds' strongly suggests a computational bottleneck – high CPU usage. The problem is likely an inefficient algorithm or processing logic that's consuming significant CPU cycles when handling large datasets. Options A, B, and C are potential problems but don't directly explain the prolonged response times.
11 / 13
John, a senior developer, is describing a finding from a recent performance test:
'We observed that our service spends over 80% of its execution time waiting for external API calls. This is impacting overall response times significantly.' What technique would be MOST valuable to investigate the root cause of this latency?
While caching and increasing RAM might offer some benefits, the core issue is *external* latency. Profiling the external API calls—measuring their response times and identifying slow endpoints—is crucial for understanding where the bottleneck lies. A code review would focus on your application's code, not the third-party service's performance. This targeted approach provides actionable insights.
12 / 13
Emily reports a problem in her Slack channel:
'Users are complaining about slow loading times when viewing product details. The monitoring shows high latency on the server responsible for retrieving product information from our database.' What is a key area to investigate *first* to address this latency?
While optimizing CSS/JavaScript and using a CDN are good practices, the immediate issue is high latency *retrieving* product data. Analyzing the SQL queries—specifically indexing and join strategies—is the most direct way to identify if the database itself is the bottleneck. Inefficient queries can dramatically increase query execution time, leading to slow loading times.
13 / 13
Mark, a developer, sends you this message:
'I've been running some load tests on the user authentication service. The response times are consistently high – around 2 seconds for successful logins. The logs show that the system is spending a lot of time validating user credentials against our database.' What should Mark investigate to reduce these latency issues?
The logs indicating prolonged credential validation strongly suggest that the database is the bottleneck. Optimizing the database schema, specifically adding appropriate indexes for user credentials, will dramatically improve the speed of this process. While rate limiting, increasing threads, and changing protocols are all potentially valid strategies, they address *different* problems – the root cause here is inefficient database access.
What will I practise in "Bottleneck Identification Language"?
This module focuses on Performance Profiling — real workplace phrasing you'll use on the job. It contains 13 scenario-based multiple-choice questions with instant feedback.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account or sign-up required.
How many questions does this exercise have?
This module includes 13 questions. Each one gives an immediate right/wrong result plus a full explanation of the correct phrasing.
What happens if I answer a question incorrectly?
You'll see the correct answer highlighted straight away, along with a plain-English explanation of why it's right and why the other options don't fit — mistakes are part of the learning here.
Can I retry the exercise if I want a better score?
Yes — use the 'Try again' button on the results screen to reset your score and go through the questions again. There's no limit on attempts.
Who is this Performance Profiling exercise for?
It's aimed at IT professionals with working English who want to sound more natural and precise around performance profiling — useful whether you're preparing for real conversations at work or just building confidence with the vocabulary.
Do I need an account to track my progress?
No account is needed. Your progress through the exercise is tracked locally in your browser for the current session, and you can replay the module at any time.
How is this different from reading a blog article?
This exercise is an interactive drill that tests and reinforces specific phrasing through multiple-choice questions with instant feedback, while blog articles explain concepts and vocabulary in prose. The two work well together.
Where can I find more Performance Profiling exercises?
See the Performance Profiling hub for more modules like this one, or browse the full Exercises page for other IT-English topics.
Can I complete this exercise on my phone?
Yes — every exercise on CoderSlingo is fully responsive and works on phones and tablets, so you can practise anywhere.