Thread- und Connection-Pool-Tuning

Status: verifiziert, dass die Konfiguration syntaktisch korrekt ist und der Server sie anstandslos übernimmt (kein Config-Fehler/-Warning im Log). Nicht verifiziert: das tatsächliche Verhalten unter Last (dafür fehlt ein Lasttest in diesem Projekt) — bewusst transparent, weil "Pool-Größe X ist optimal" ohne echte Lastmessung reine Behauptung wäre.

Thread-Pool: <executor>

<executor id="default" name="Default Executor" coreThreads="10" maxThreads="50"/>

So konfiguriert in concordia-portal/src/main/liberty/config/server.xml. Ohne dieses Element verwendet Liberty einen intern berechneten Default (an CPU-Kernzahl gekoppelt) — für Produktion explizit zu setzen ist der richtige Reflex, aus zwei Gründen:

1. Reproduzierbarkeit: derselbe Server auf unterschiedlicher Hardware (Dev-Laptop vs. Produktions-VM) bekommt sonst unterschiedliche Pool-Größen, ohne dass das irgendwo sichtbar dokumentiert ist.
2. Bewusste Obergrenze: maxThreads begrenzt, wie viele Anfragen gleichzeitig bearbeitet werden — ohne Obergrenze kann ein Lastspitzen-Szenario den Server (und dahinterliegende Ressourcen wie DB2-Connections, siehe unten) überrennen, statt kontrolliert Anfragen in eine Warteschlange zu stellen.

Verifiziert: Server mit dieser expliziten Config gestartet, kein CWWKG0083W (ungültiges Attribut) oder ähnliche Warnung im Log, /health weiterhin mit 200 erreichbar — die Config wird also syntaktisch korrekt angenommen.

Connection-Pool: <connectionManager>

Aus docs/40-bindeglied-dev-ops-db2-netzwerk/02-der-bindeglied-prozess.md (dort mit vollem DB2-Kontext):

<connectionManager id="coreBankingConnMgr" maxPoolSize="10" minPoolSize="2"/>

Der entscheidende Unterschied zum Thread-Pool: bei einer Verbindung zu DB2 for z/OS ist eine großzügige Poolgröße nicht einfach "mehr Puffer", sondern potenziell ein Kostenfaktor (MSU-Verbrauch, WLM-Klassifizierung) — siehe docs/40-bindeglied-dev-ops-db2-netzwerk/01-db2-fuer-zos-und-mainframe-grundlagen.md. Ein WAS-Admin sollte diese beiden Pool-Arten deshalb bewusst unterschiedlich behandeln:

Faustregel für die Größenfindung (ohne Anspruch auf Vollständigkeit)

Kein Ersatz für echten Lasttest, aber als Ausgangspunkt für ein erstes sinnvolles Sizing:

• Thread-Pool grob an erwarteter Nebenläufigkeit orientieren (gleichzeitige Nutzer × Anteil, der tatsächlich aktiv Anfragen stellt), nicht an der Gesamtnutzerzahl.
• Connection-Pool zu einer Backend-Ressource i. d. R. kleiner als der Thread-Pool wählen — nicht jede Anfrage braucht die ganze Zeit eine offene DB-Verbindung, und ein zu großer DB-Pool kann selbst zum Flaschenhals werden (z. B. wenn die Datenbank selbst eine Verbindungs-Obergrenze hat, die von mehreren Anwendungen geteilt wird — bei DB2 for z/OS mit vielen angeschlossenen Anwendungen ein sehr reales Szenario).
• Monitoring vor Tuning: siehe 02-heap-und-thread-dumps.md — erst messen (Thread-Dump: wie viele Threads warten wirklich auf Pool-Kapazität?), dann anpassen, nicht umgekehrt raten.