Free-threading vs the GIL in mod_wsgi 6.0.0 - Graham Dumpleton

A prior benchmark tuned WSGISwitchInterval to recover throughput for a CPU-bound Python workload under mod_wsgi daemon groups. Tightening the switch interval improved throughput but did not change per-process CPU usage because each process remained limited to about one core by the GIL. The new focus is on what changes when that ceiling is removed. PEP 703 free-threading provides a CPython build without a GIL, and mod_wsgi 6.0.0 enables it via the WSGIFreeThreading directive. With no GIL, a process can use multiple cores as its threads can fill them. GIL wait time and its related histograms disappear, and CPU usage per process becomes the primary evidence of genuine parallelism.

"This post is about what happens when that ceiling is removed. PEP 703 free-threading provides a CPython build with no GIL at all, and mod_wsgi 6.0.0 exposes the opt-in for it through WSGIFreeThreading, the second directive covered in this series. I have rerun the same benchmark workload on a free-threaded Python with that directive on. The interesting metric is now CPU usage per process."

"With the GIL, threads in a process serialise on the lock, and the process consumes at most one core regardless of how many threads you give it. With free-threading there is no GIL, and the process can use as many cores as its threads can actually fill. If the workload is CPU-bound Python, CPU usage per process is what tells you whether the runtime is making real use of the hardware."

"GIL wait time was the central diagnostic in the switch-interval post. Under free-threading there is no GIL, so there is no GIL wait to measure. The histogram that showed the convoy bumps at multiples of the switch interval in the previous post goes flat by definition. What replaces it as positive evidence that the workload is genuinely parallel is the CPU usage number itself. Multiple cores per process is the new signal."

Read at Grahamdumpleton