How do you measure whether a Python workload is CPU-bound, I/O-bound or connection-bound?

## Three classes, not two The usual framing is CPU-bound versus I/O-bound, but a third class matters as soon as you build servers: connection-bound. A search-index rebuilder that takes 27 minutes is CPU-bound if those minutes are spent tokenizing documents in Python, I/O-bound if they are spent streaming documents off a slow store, and connection-bound if the same process must simultaneously hold ten thousand mostly-idle sockets open while doing almost nothing per socket. The three classes select different models, so the classification is the actual interview answer; the model name is a consequence. ## The ratio that classifies Run one representative unit of work and record two clocks: - `time.perf_counter` — elapsed wall time, including every wait. - `time.process_time` — CPU time this process consumed, sleeps excluded. Divide. A ratio near 1.0 says the code is executing, not waiting: CPU-bound. Near 0 says it is parked in a syscall: I/O-bound. Anything in between is mixed, which is the common real answer, and then the useful question becomes which half dominates the tail. `time.thread_time` narrows the same measurement to one thread when you are already running a pool. Two cautions make this measurement honest. First, measure a *single* unit of work, not the whole job under the current model — if you already run eight threads that are fighting for the lock, wall time is inflated by contention and the ratio lies. Second, `time.process_time` counts CPU spent anywhere in the process, including inside C extensions; a job that looks CPU-bound may be burning that CPU in native code that already releases the interpreter lock, in which case threads scale and processes are unnecessary. ## Where the CPU time goes Once the ratio says CPU-bound, `cProfile` (or a sampling profiler) tells you whether the frames are Python or a thin wrapper over native work. That distinction decides between two very different prescriptions: - Hot pure-Python frames → the interpreter lock caps you at one core, so the choice is processes, the free-threaded build, or making the Python code itself cheaper. - Hot native frames in a library that releases the lock → threads already parallelize; adding processes buys nothing and costs serialization. And very often the profile reveals a fourth answer: the algorithm. Cutting the per-item work in half beats every concurrency model, costs no new failure modes, and does not need a deployment story. ## Recognizing connection-bound Connection-bound work is identified by counting, not timing: how many operations must be in flight at once, and how much memory each one holds while it waits. If the answer is a few hundred, a thread pool is fine and far simpler. If it is tens of thousands, per-waiter cost dominates — an OS thread reserves a large stack and a scheduler slot, while an `asyncio` task waiting on a socket is a small object plus its frame. That is the case where asyncio wins on capacity rather than on speed. ## Mixed workloads Real jobs are rarely pure. The productive move is to split the pipeline at the boundary and measure each stage separately: fetch stages come out I/O-bound, transform stages CPU-bound. Then you can run the fetch stage with threads or asyncio and hand only the transform stage to processes, instead of forcing one model onto both. If a stage genuinely mixes both, decide by the tail: whichever half owns the p99 chooses the model, and the other half rides along — for example an async pipeline that offloads occasional heavy computation to a worker pool. ## What good sounds like A strong answer names the measurement, states the number it produced, and only then picks a model. A weak answer starts with the model. Interviewers ask this precisely because it separates people who have profiled a real job from people repeating a rule of thumb about the GIL.