Zwischen Threads, Prozessen und asyncio für eine Python-Arbeitslast wählen

Ziel

Das Nebenläufigkeitsmodell wählen, das zum Engpass der Arbeitslast passt, bevor sich das Design um ein falsches herum verfestigt.

Voraussetzungen

Ein Profil oder eine Messung, die zeigt, wohin die Zeit auf dem Hot Path geht: Warten auf I/O (Sockets, Datenträger, Subprozesse), Ausführen von Python-Bytecode (Parsen, reine Python-Zahlenverarbeitung), oder Ausführen von nativem Code, der das GIL freigibt (Kompression, Hashing, viele Array-Operationen). Siehe "Vor der Optimierung profilieren".

Schritte

1. Die gleichzeitigen Wartevorgänge zählen. Tausende Verbindungen oder von Haus aus asynchrone Bibliotheken sprechen für asyncio. Ein paar Dutzend blockierende Aufrufe über synchrone Bibliotheken sprechen für einen ThreadPoolExecutor; die Dokumentation gibt dessen Standard-Worker-Anzahl mit min(32, cpu_count + 4) an (seit 3.13 auf Basis von os.process_cpu_count()), gewählt, um für I/O-lastige Aufgaben mindestens fünf Worker zu erhalten.
2. Liegt der Engpass bei Python-Bytecode, helfen Threads beim Standard-Build nicht: Das Glossar definiert das GIL als den Mechanismus, der zu jedem Zeitpunkt nur einem Thread erlaubt, Python-Bytecode auszuführen. ProcessPoolExecutor (oder multiprocessing) verwenden, oder einen Free-Threaded-Build, wenn jede Abhängigkeit ihn unterstützt.
3. Liegt der Engpass bei nativem Code, der das GIL freigibt, liefern Threads Parallelität ohne die Serialisierungskosten von Prozessen; das mit einem Lauf mit zwei gegenüber einem Worker auf echten Daten bestätigen.
4. Bei Prozessen die Startmethode explizit mit get_context() setzen. Die Dokumentation hält fest, dass sich der Standard auf POSIX in Python 3.14 von fork zu forkserver geändert hat und dass macOS seit 3.8 standardmässig spawn verwendet; Argumente und Ergebnisse müssen picklebar sein, daher Bezeichner statt grosser Objekte übergeben und Verbindungen innerhalb des initializer des Workers öffnen.
5. Alles begrenzen: max_workers, ein asyncio.Semaphore, oder eine Warteschlangengrösse; unbegrenztes Fan-out verschiebt den Fehler zum nachgelagerten Dienst.
6. Modelle gezielt kombinieren: asyncio.to_thread für einen blockierenden Aufruf innerhalb einer Schleife, loop.run_in_executor mit einem Prozess-Pool für CPU-Arbeit innerhalb eines asynchronen Servers.
7. Den Abschaltpfad schreiben: executor.shutdown(cancel_futures=True), Task-Abbruch, und ein Timeout auf jedem future.result().

Erwartetes Ergebnis

Eine kurze Entscheidungsnotiz, die Engpass, Modell, Begrenzung und Startmethode benennt, dazu ein kleiner Benchmark, der zeigt, dass das gewählte Modell die Einzelthread-Baseline auf der echten Arbeitslast schlägt.

Grenzen und Prüfbasis

Die Regeln folgen der zitierten Dokumentation, nicht Messungen. Gemischte Arbeitslasten brauchen unter Umständen zwei Pools. Free-Threaded-Builds verändern Schritt 2; siehe den Artikel zum GIL und die offene Frage dazu, wann sich solche Builds lohnen.