In this lesson, you will learn how to use the horizontal span of functions in a flame graph to identify which bottlenecks are suppressing your application's throughput.
Understanding Width as Time
When you generate a CPU profile in Node.js using node --prof or the Chrome DevTools inspector, you create a visualization where the x-axis represents the total duration of the sampling period. Because a flame graph is a statistical representation of the call stack over time, the width of a function block directly correlates to its cumulative CPU consumption.
If your service is struggling with low throughput under load, you shouldn't just look for deep call stacks; you should look for "plateaus"—wide, flat bars near the top of the graph. These wide bars indicate that the CPU spent a disproportionate amount of its total lifecycle executing that specific function.
Analyzing the "Hot" Plateau
Imagine your request handler calls a data transformation utility. If the transformData() block takes up 60% of the total width of the flame graph, it means that even if you have 10,000 requests per second, that function is effectively the "chokepoint" for every single one of them.
Consider this conceptual scenario:
// A wide block usually indicates a sync operation blocking the event loop
function processLargePayload(data) {
// Expensive synchronous JSON serialization or regex parsing
return JSON.stringify(data).replace(/pattern/g, 'replacement');
}
In your flame graph, processLargePayload will appear as a very wide bar. If you see this width persisting across multiple samples, it confirms that the function is a throughput killer. Because Node.js is single-threaded, if a function takes up 50% of the total graph width, your total system throughput is mathematically capped; you simply cannot process more requests than the remaining 50% of CPU time allows.
Tactical Comparison
To analyze throughput, compare the widths of your business logic blocks against the framework overhead. If express or fastify framework internals occupy more width than your actual business logic, the bottleneck is structural. If your business logic functions (like the processLargePayload example) are the widest bars, that is where your performance optimization effort will yield the highest throughput gains.
Key Takeaway: In a flame graph, the width of a function block is directly proportional to its CPU cost; focus your optimization efforts on the widest bars to maximize request throughput.