How would you decide if PyPy suits a webhook receiver peaking at 1,200 requests per minute?

This is a decision question, not a trivia question, and the discipline is to establish the problem before shopping for a solution. ## Size the problem honestly Twelve hundred requests a minute is twenty a second. That number is small enough that the first question is whether there is a CPU problem at all, or a latency problem, or simply a cost target. Ask what is actually being violated: - a p99 latency objective, - CPU headroom at peak, - or the monthly bill. Then profile a real worker under real traffic and split its CPU time into pure-Python bytecode, time inside compiled dependencies, and time blocked on I/O. ## Apply the ceiling before the benchmark Only the pure-Python fraction can benefit. If signature verification, serialization and the network account for 60% of wall time and parsing accounts for 40%, then even a four-times faster interpreter on that 40% yields under a 1.4x improvement end to end. Computing that ceiling on a napkin takes a minute and frequently ends the discussion, which is exactly what you want it to do. ## Exhaust the cheaper moves first In rough order of cost: 1. fix the algorithm or the allocation churn in the hot parser; 2. stop doing work you can cache or batch; 3. move the one hot loop into a compiled path and leave the runtime alone; 4. or simply add processes — at twenty requests a second, another instance is usually cheaper than a runtime migration and carries none of the ongoing tax. A runtime change is one of the most expensive interventions available, so it should be justified against those, not against doing nothing. ## Gate one: process lifetime A tracing JIT converts interpreter overhead into warm-up cost, and warm-up only amortizes in a long-lived process. So ask how long a worker actually lives. If workers are recycled after a fixed number of requests to paper over a leak, if autoscaling churns instances, or if the deployment is a short-lived container per burst of work, the compiled traces are discarded before they repay their cost. Also ask what happens right after every deploy: the first requests on a cold worker are slower, and if your p99 objective is measured over a window that includes deploys, that spike is now part of your SLO story. ## Gate two: the dependency audit Enumerate every transitively-installed package that ships a compiled artifact and confirm each: - has a working build on the target runtime, - that its own tests pass there, - and that it is not called so finely that boundary costs dominate. Add the operational dependencies people forget: profilers, debuggers, monitoring agents and coverage tooling all have to work on the new runtime, or you have traded throughput for blindness. ## Gate three: resource shape and language level - Baseline memory per worker is higher and compiled traces add more, so on a memory-bound fleet you may fit fewer workers per node and lose in aggregate what you gained per request. - And the runtime's supported language level pins your syntax and your dependency versions — a codebase using recent language features may not run there at all. ## Then pilot, with a number agreed in advance Stand the alternative runtime beside the current one and feed both replayed production traffic, not synthetic load. Real payloads are what surface behaviour that generated ones never do — the malformed body, the unusual content type, the encoding mismatch that drives a parser down a fallback path whose cost differs between runtimes. Measure: - CPU time per request at steady state, - resident memory per worker, - p50 and p99 including a window immediately after restart, - and error parity against the incumbent. Write the exit criterion before you start — for example, *at least a two-times reduction in CPU per request at the 1,200-per-minute peak, every dependency green, and no new error classes, or we revert* — because otherwise the decision gets made by whoever is most enthusiastic. ## Weigh the standing cost, not just the benchmark A second interpreter in the fleet means a second CI matrix, second base images, a second set of build problems when a dependency updates, and an on-call population that has to reason about an unfamiliar garbage collector at three in the morning. That tax is paid every month; the speedup is measured once. For a genuinely interpreter-bound, long-running fleet the trade can be excellent — the question is whether this one is that. ## Keep the option cheap either way The most valuable output of this analysis is often not the migration but the discipline that keeps it available: - no reliance on immediate reference-count finalization, - resources closed with `with` blocks rather than left to the collector, - compiled dependencies isolated behind a narrow interface, - and occasionally running the test suite on a second implementation in CI so drift surfaces early. That costs almost nothing and keeps the decision reversible. ## And name the runtimes that are not answers here Alternative implementations exist for very different reasons — embedding Python inside another managed runtime, or running on microcontrollers. Reaching for one of those to solve a throughput problem on a server is a category error, and saying so is part of a good answer.