--- { "title": "Health Samurai Lab: Game of Pools", "description": "Wir haben die Pool-Einstellungen von Aidbox einem Lasttest unterzogen. 80 Konfigurationen zeigen, wie Web-Threads und DB-Pools den Durchsatz und die Latenz beeinflussen.", "date": "2026-02-09", "author": "Marat Surmashev", "reading-time": "10 minutes", "tags": [ "Health Samurai Lab", "Database", "Infrastructure" ] } --- Wie die meisten Webanwendungen besteht Aidbox aus einer eingehenden Web-Anfrage-Warteschlange, einem Pool von Web-Workern, die Anfragen verarbeiten, sowie einem Pool von Datenbankverbindungen. Diese beiden Pools – Web-Worker und Datenbankverbindungen (DB) – spielen eine zentrale Rolle für die Aidbox-Performance. Gemeinsam bestimmen sie, wie effizient die Serverressourcen genutzt werden. Aidbox ermöglicht es Ihnen, die Größen dieser Pools über die Einstellungen `BOX_WEB_THREAD` und `BOX_DB_POOL_MAXIMUM_POOL_SIZE` zu konfigurieren. Dies wirft die Frage auf: Welche optimalen Parameter sollte ich für meine konkrete Installation angeben? Der gesunde Menschenverstand legt nahe, dass die Anzahl der Web-Threads mit den verfügbaren CPU-Kernen auf Ihrem Server skalieren sollte, während der Datenbankverbindungspool groß genug sein sollte, um alle aktiven Web-Worker plus eine kleine Reserve für Hintergrundaufgaben zu bedienen. Auf dieser Grundlage lautete die Empfehlung von Health Samurai: `BOX_WEB_THREAD = 2 × CPU_COUNT` und `BOX_DB_POOL_MAXIMUM_POOL_SIZE = 2 × BOX_WEB_THREAD`. Diese Empfehlung ist grundsätzlich logisch und stimmt mit dem Verständnis der Funktionsweise des Web-Stacks überein. Sie wurde durch unsere Erfahrung im Betrieb von Aidbox bestätigt. Allerdings war sie bis jetzt nicht durch systematische Lasttests unter anhaltender Last validiert worden. ## Testumgebung Um die Aidbox-Performance isoliert zu messen, haben wir alle Tests lokal auf einem dedizierten Server durchgeführt, mit einer lokalen Datenbank und einem lokalen Netzwerk mit schnellen NVMe-Festplatten, um Netzwerk- und I/O-Overhead zu minimieren. Für die Ausführung der Tests haben wir das Werkzeug K6 verwendet. Die Tests führten CRUD-Operationen über neun verschiedene Ressourcentypen durch. Als Ergebnis haben wir Durchsatz und Latenz gemessen. Die vollständige Testumgebung, die Skripte und die [Ergebnisse sind im Repository verfügbar](https://github.com/Aidbox/examples/tree/main/samurai-lab/game-of-pools). ## Testszenarien Nun einige Worte dazu, wie wir Aidbox getestet haben. Da wir verschiedene CPU-Limit-Konfigurationen (2, 4, 6, 8) testen wollten, wäre es unpraktisch gewesen, die Pool-Größen für jedes CPU-Limit im Voraus festzulegen. Stattdessen verwenden wir Multiplikatoren: ```javascript CPU_LIMITS = [2, 4, 6, 8] WEB_THREAD_MULTIPLIERS = [1, 1.5, 2, 2.5, 3] DB_POOL_MULTIPLIERS = [1.5, 2, 2.5, 3] ``` Was bedeutet das? Während des Tests haben wir alle möglichen Kombinationen dieser Parameter durchlaufen. Zum Beispiel ergibt sich für 6 CPU-Kerne mit einem Web-Multiplikator von 2 und einem Datenbank-Multiplikator von 2,5 folgende Konfiguration: ```javascript services: aidbox: deploy: resources: limits: cpus: '6' # 6 CPU limit environment: BOX_INSTANCE_NAME: cpu_6__web_12__db_30 BOX_WEB_THREAD: '12' # 6 * 2 (web multiplier) BOX_DB_POOL_MAXIMUM_POOL_SIZE: '30' # 6 * 2 * 2.5 (web and db multiplier) ``` Insgesamt haben wir 80 Tests aller möglichen Konfigurationen durchgeführt. Vor jedem Test führten wir einen Warm-up durch, gefolgt von einem 5-minütigen Stresstest auf CRUD-Operationen. Eine sehr wichtige Beobachtung aus den Tests ist, dass die Größe des Datenbankpools größer sein muss als die Anzahl der Web-Worker, da Aidbox im Betrieb mehrere Verbindungen für Hintergrundaufgaben belegt, was bei der Verarbeitung einer Anfrage zu Fehlern beim Versuch führen kann, eine Datenbankverbindung zu erhalten. ## Testergebnisse Nach fast acht Stunden Tests können wir uns die Ergebnisse ansehen. Nachfolgend finden Sie die detaillierten Performance-Analysediagramme für jede CPU-Konfiguration: #### 2-CPU-Konfiguration ![Chart 1](image-1.svg) ![Chart 2](image-2.svg) #### 4-CPU-Konfiguration ![Chart 1](image-3.svg) ![Chart 2](image-4.svg) #### 6-CPU-Konfiguration ![Chart 1](image-5.svg) ![Chart 2](image-6.svg) #### 8-CPU-Konfiguration ![Chart 1](image-7.svg) ![Chart 2](image-8.svg) ### Wichtige Beobachtungen aus den Diagrammen Die Diagramme zeigen deutlich: - **Durchsatz (RPS)**: Der maximale Durchsatz wird mit einem Web-Thread-Multiplikator von 1,5x und einem DB-Pool-Multiplikator von 2–2,5x erreicht. - **P99-Latenz**: Die minimale Latenz wird mit einem Web-Thread-Multiplikator von 1x und einem DB-Pool-Multiplikator von 1,5–2x beobachtet. - **[Skalierung](/blog/aidbox-horizontal-vs-vertical-scaling)**: Nahezu lineare Performance-Skalierung mit zunehmender Anzahl von CPU-Kernen. - **Kompromisse**: Klare umgekehrte Beziehung zwischen Durchsatz und Latenz bei zunehmender Größe der WEB-Threads. ## Zusammenfassung Die Testergebnisse bestätigen unsere bisherigen Empfehlungen und das allgemeine Verständnis davon, wie sich Aidbox unter Last verhält. Wir haben lediglich eine praktische Bestätigung in Zahlen erhalten. Zusammenfassend lautet die allgemeine Empfehlung für `BOX_DB_POOL_MAXIMUM_POOL_SIZE`: `2 × BOX_WEB_THREAD`. Eine Erhöhung der Datenbankpool-Größe bringt keinen Performance-Gewinn und führt in einigen Fällen zu einer Verschlechterung. Diese Verschlechterung ist nicht signifikant und liegt innerhalb der Messfehlertoleranz, war jedoch dennoch nachvollziehbar. In unseren detaillierten Dashboards haben wir bei einer erhöhten DB-Pool-Größe häufigere GC-Aktivitäten beobachtet, was auf zusätzlichen Overhead für die Verwaltung eines großen Datenbankverbindungspools hinweisen kann. Die allgemeine Empfehlung für `BOX_WEB_THREAD` lautet `1,5 × CPU_COUNT`. Dies bietet die beste Balance zwischen Durchsatz und Latenz und ist für die meisten Projekte optimal. Für Projekte wie EHR, PHR, Patientenportale und ähnliche, bei denen viele kurze und schnelle OLTP-Operationen anfallen und bei denen Systemreaktionsfähigkeit sowie minimale Latenz für eine bessere Endbenutzererfahrung wichtiger sind, empfiehlt es sich, `BOX_WEB_THREAD` auf `1 × CPU_COUNT` zu setzen. Für CDR-Systeme, bei denen viele lange und komplexe Such- und Analyseabfragen anfallen, viele Massenimporte durchgeführt werden und der Großteil der Arbeit auf die Datenbank entfällt, empfiehlt es sich, `BOX_WEB_THREAD` auf `2 × CPU_COUNT` zu setzen. Nachfolgend finden Sie eine Übersichtstabelle mit empfohlenen Parametern: | CPU-Anzahl | Anwendungsfall | WEB-Threads | DB-Pool-Größe | | --- | --- | --- | --- | | 2 | Ausgewogen (Empfohlen) | 3 | 6 | | 2 | Niedrige Latenz | 2 | 4 | | 2 | Hoher Durchsatz | 4 | 8 | | 4 | Ausgewogen (Empfohlen) | 6 | 12 | | 4 | Niedrige Latenz | 4 | 8 | | 4 | Hoher Durchsatz | 8 | 16 | | 6 | Ausgewogen (Empfohlen) | 9 | 18 | | 6 | Niedrige Latenz | 6 | 12 | | 6 | Hoher Durchsatz | 12 | 24 | | 8 | Ausgewogen (Empfohlen) | 12 | 24 | | 8 | Niedrige Latenz | 8 | 16 | | 8 | Hoher Durchsatz | 16 | 32 | Dies sind allgemeine empfohlene Parameter, die auf synthetischen Tests basieren und verschiedene Aspekte des Gesamtbetriebs des Systems nicht berücksichtigen, wie etwa Importe, Datenbankwartung usw. In jedem Fall ist es besser, ähnliche Tests in Ihrer eigenen Umgebung durchzuführen, um optimale Parameter speziell für Ihr System zu ermitteln. Sie können diese Zahlen als Ausgangspunkt für die Feinabstimmung Ihres Systems verwenden. Falls Sie Hilfe bei der Optimierung von Aidbox für Ihre Workload oder Infrastruktur benötigen, [nehmen Sie Kontakt mit uns auf](https://www.health-samurai.io/contacts?utm_source=blog&utm_medium=article&utm_campaign=game-of-pools). Eine interessante Beobachtung, die wir heute gemacht haben, ist die nahezu lineare Performance-Skalierung mit zunehmender Anzahl von CPU-Kernen. Nun, das werden wir im nächsten Blogbeitrag testen. Marat Surmashev, VP of Engineering Siehe auch: [FHIR produktionsbereit machen](/blog/first-steps-to-get-your-fhir-based-solution-ready-for-production).