{"id":18136,"date":"2026-03-06T11:50:48","date_gmt":"2026-03-06T10:50:48","guid":{"rendered":"https:\/\/webhosting.de\/webserver-worker-modelle-prefork-worker-event-mpm-serverperf\/"},"modified":"2026-03-06T11:50:48","modified_gmt":"2026-03-06T10:50:48","slug":"%e3%82%a6%e3%82%a7%e3%83%96%e3%82%b5%e3%83%bc%e3%83%90%e3%83%bc-%e3%83%af%e3%83%bc%e3%82%ab%e3%83%bc-%e3%83%a2%e3%83%87%e3%83%ab-prefork-%e3%83%af%e3%83%bc%e3%82%ab%e3%83%bc-%e3%82%a4%e3%83%99","status":"publish","type":"post","link":"https:\/\/webhosting.de\/ja\/webserver-worker-modelle-prefork-worker-event-mpm-serverperf\/","title":{"rendered":"Apache Worker\u30e2\u30c7\u30eb\uff1aPrefork\u3001Worker\u3001Event\u306e\u6bd4\u8f03"},"content":{"rendered":"<p><strong>Apache Worker Modelle<\/strong> bestimmen, wie der Apache HTTP Server Anfragen parallel verarbeitet und Ressourcen nutzt \u2013 konkret \u00fcber die MPMs Prefork, Worker und Event. In diesem Beitrag zeige ich, wie sich die drei Modelle technisch unterscheiden, welche Auswirkungen sie auf <strong>Leistung<\/strong> und Skalierung haben und welches Setup in realen Szenarien \u00fcberzeugt.<\/p>\n\n<h2>Zentrale Punkte<\/h2>\n<p>Die folgenden Stichpunkte geben dir einen schnellen \u00dcberblick \u00fcber die wichtigsten Unterschiede und Entscheidungen rund um die drei MPMs; danach gehe ich auf Details ein und liefere <strong>Praxiswissen<\/strong>.<\/p>\n<ul>\n  <li><strong>Prefork<\/strong>: Prozessbasiert, hohe Isolation, hoher RAM-Bedarf.<\/li>\n  <li><strong>Worker<\/strong>: Threads je Prozess, gute Skalierung, sensibel bei Keep-Alive.<\/li>\n  <li><strong>Event<\/strong>: Event-Loop entkoppelt Verbindung und Anfrage, sehr effizient.<\/li>\n  <li><strong>Tuning<\/strong>: StartServers, ThreadsPerChild, MaxRequestWorkers gezielt setzen.<\/li>\n  <li><strong>HTTP\/2<\/strong>: Funktioniert sinnvoll mit Worker und Event, nicht mit Prefork.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/apache-servermodelle-vergleich-8742.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Was MPMs in Apache steuern<\/h2>\n\n<p>Mit den Multi-Processing Modules (MPMs) lege ich fest, ob Apache pro Anfrage Prozesse oder Threads nutzt und wie der Server <strong>Parallelit\u00e4t<\/strong> bereitstellt. Prefork erzeugt viele Prozesse mit je einem Thread, Worker wenige Prozesse mit vielen Threads, Event baut auf Worker auf und entkoppelt Verbindungen von der eigentlichen Bearbeitung. Diese Wahl wirkt sich direkt auf Speicher, CPU-Auslastung und Latenzen aus. Ich ber\u00fccksichtige deshalb immer Sessions, Keep-Alive, Protokolle wie HTTP\/2 und die verwendeten Module. Wer MPMs ignoriert, verschenkt messbare <strong>Performance<\/strong> und riskiert Engp\u00e4sse.<\/p>\n\n<h2>Prefork: Prozessisolierung und Kompatibilit\u00e4t<\/h2>\n\n<p>Prefork setzt auf einzelne Prozesse je Anfrage und liefert damit starke <strong>Isolation<\/strong>. St\u00fcrzt ein Prozess ab, bleiben andere unber\u00fchrt \u2013 das erh\u00f6ht die Fehlertoleranz bei unsauberem Code oder alten Erweiterungen. Der Preis: Jeder Prozess bringt eigenen Overhead mit, sodass der RAM-Verbrauch pro paralleler Verbindung steigt. Bei 100 gleichzeitigen Anfragen entstehen 100 Prozesse, was ich nur bei geringer bis mittlerer Last akzeptabel finde. Ich nutze Prefork vor allem, wenn ich Module ohne Thread-Sicherheit einsetzen muss oder wenn legacy CGI-Skripte hohe <strong>Trennung<\/strong> erfordern.<\/p>\n\n<h2>Worker: Threads und hohe Parallelit\u00e4t<\/h2>\n\n<p>Beim Worker-Modell f\u00fchren einzelne Prozesse mehrere Threads aus, wodurch der Speicherbedarf pro Anfrage <strong>sinkt<\/strong>. Diese Architektur erlaubt deutlich mehr Concurrency auf derselben Hardware und eignet sich f\u00fcr hohe Zugriffszahlen. Lange Keep-Alive-Verbindungen k\u00f6nnen jedoch Threads binden und damit Kapazit\u00e4t blockieren. In sauberen, thread-sicheren Setups \u2013 etwa mit PHP-FPM \u2013 erreiche ich mit Worker sehr gute RPS-Werte bei moderatem RAM-Einsatz. Ich setze Worker ein, wenn ich eine effiziente, threadbasierte <strong>Skalierung<\/strong> brauche und Keep-Alive sinnvoll gesteuert wird.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/ApacheWorkerModelleComparison3564.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Event: Nicht-blockierende Keep-Alive-Strategie<\/h2>\n\n<p>Event baut auf dem Worker-Modell auf, behebt aber die Keep-Alive-Schw\u00e4che durch einen <strong>Event-Loop<\/strong>. Ein Thread bearbeitet nur die eigentliche Anfrage; das Halten der Verbindung \u00fcbernimmt ein separater Mechanismus. Dadurch bleiben Threads frei, und die Maschine verarbeitet mehr gleichzeitige Sessions mit niedriger Latenz. Bei HTTP\/2-Verbindungen \u00fcberzeugt Event besonders, da Multiplexing und lange Verbindungen ohne Thread-Verschwendung laufen. In modernen Setups starte ich mit Event als <strong>Standardbasis<\/strong> und passe nur um, wenn Module oder Legacy-Anforderungen entgegenstehen.<\/p>\n\n<h2>Tabellarischer Vergleich der MPMs<\/h2>\n\n<p>Die folgende Tabelle verdichtet die zentralen Unterschiede, damit ich auf einen Blick <strong>einsch\u00e4tzen<\/strong> kann, welches Modell zur Last- und Modul-Situation passt. Vor dem Wechsel pr\u00fcfe ich stets die Thread-Sicherheit aller Module und die erwartete Verbindungsdauer. Danach ordne ich MaxRequestWorkers, ThreadsPerChild und weitere Limits den verf\u00fcgbaren Ressourcen zu. Die Tabelle hilft mir, erste Annahmen zu treffen, ersetzt aber keine Lasttests unter realen Bedingungen. Gerade bei Event lohnt eine Messung mit langen Keep-Alive-Phasen und HTTP\/2, um die <strong>Vorteile<\/strong> sichtbar zu machen.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>MPM<\/th>\n      <th>Prozesse\/Threads<\/th>\n      <th>RAM-Verbrauch<\/th>\n      <th>Zuverl\u00e4ssigkeit<\/th>\n      <th>Typische Nutzung<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Prefork<\/td>\n      <td>1 Thread je Prozess<\/td>\n      <td>Hoch<\/td>\n      <td>Hoch (gute Isolation)<\/td>\n      <td>Geringe\/mittlere Last, Module ohne Thread-Sicherheit, klassische CGI<\/td>\n    <\/tr>\n    <tr>\n      <td>Worker<\/td>\n      <td>Mehrere Threads je Prozess<\/td>\n      <td>Mittel<\/td>\n      <td>Mittel<\/td>\n      <td>Hohe Last mit thread-sicherem Stack, z. B. PHP-FPM<\/td>\n    <\/tr>\n    <tr>\n      <td>Event<\/td>\n      <td>Threads + Event-Loop<\/td>\n      <td>Niedrig<\/td>\n      <td>Hoch<\/td>\n      <td>Sehr hohe Last, lange Verbindungen, HTTP\/2<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Ich lese aus der Tabelle: Prefork punktet bei <strong>Abschirmung<\/strong>, Worker bei Effizienz und Event bei maximaler Auslastung unter gleichzeitigen Verbindungen. F\u00fcr neue Projekte nutze ich Event, sofern keine Inkompatibilit\u00e4ten dagegen sprechen. F\u00fcr best\u00e4ndige Legacy-Stacks kann Prefork weiterhin sinnvoll sein. Wer erst migriert, erreicht mit Worker oft schon deutliche Fortschritte. Die Wahl bleibt am Ende eine <strong>Abw\u00e4gung<\/strong> aus Modulen, Traffic-Profil und Hardware.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/apache-worker-models-comparison-8294.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Leistung messen: Benchmarks und Metriken<\/h2>\n\n<p>Ohne Messung bleibt jede MPM-Entscheidung eine <strong>Vermutung<\/strong>. In Vergleichstests liefert Worker bei hoher Last bis zu rund 50 % mehr Requests pro Sekunde als Prefork; Event legt dar\u00fcber hinaus zu, vor allem bei langen Keep-Alive-Phasen. Beim Speicher zeigen sich klare Unterschiede: Bei etwa 1000 gleichzeitigen Verbindungen landen Prefork-Setups grob bei 2\u20134 GB RAM, Worker bei 1\u20132 GB, Event meist unter 1 GB. Ich pr\u00fcfe nicht nur RPS, sondern auch Time to First Byte, 95.\/99.-Perzentile und Fehlerquoten. Entscheidend ist das Lastprofil der Anwendung, denn kurze, schnelle Requests verhalten sich anders als Streaming oder <strong>WebSockets<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/Apache_Worker_Modelle_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Tuning-Parameter erkl\u00e4rt: StartServers, ThreadsPerChild, MaxRequestWorkers<\/h2>\n\n<p>Ich beginne mit konservativen Werten und skaliere hoch, bis ich die gew\u00fcnschte <strong>Auslastung<\/strong> treffe. F\u00fcr Prefork setze ich MaxRequestWorkers anhand des verf\u00fcgbaren Speichers und der Prozessgr\u00f6\u00dfe an; f\u00fcr Worker und Event plane ich ThreadsPerChild und die Zahl der Prozesse so, dass ThreadsPerChild \u00d7 Prozesse = MaxRequestWorkers ergibt. Dabei achte ich auf gen\u00fcgend Puffer, damit Lastspitzen nicht zu 503-Fehlern f\u00fchren. Ein sauberer StartServers-Wert verhindert unn\u00f6tige Forks unter Kaltstartbedingungen. Wer tiefer einsteigen will, findet Hintergrundwissen zur <a href=\"https:\/\/webhosting.de\/threadpool-webserver-apache-nginx-litespeed-optimierung-konfiguration\/\">Threadpool-Optimierung<\/a>, das sich direkt in Apache-Setups \u00fcbertragen l\u00e4sst.<\/p>\n\n<pre><code># Beispiel: Event (Debian\/Ubuntu)\na2dismod mpm_prefork mpm_worker\na2enmod mpm_event\nsystemctl restart apache2\n\n# Worker-Threading sinnvoll ausreizen\n# \/etc\/apache2\/mods-available\/mpm_event.conf\nServerLimit           16\nStartServers          4\nThreadsPerChild       50\nMaxRequestWorkers     800\nMaxConnectionsPerChild 0\n<\/code><\/pre>\n\n<p>Ich pr\u00fcfe danach den Effekt mit Benchmarks und kontrolliere, ob die CPU ausreichend <strong>arbeiten<\/strong> kann, ohne in Kontextwechsel zu ertrinken. Parallel beobachte ich RAM-Trends, Swap-Aktivit\u00e4t und offene File-Deskriptoren. Werden Queues sichtbar voll, erh\u00f6he ich vorsichtig MaxRequestWorkers oder reduziere Keep-Alive-Zeiten. L\u00e4uft alles rund, sichere ich die Konfiguration und dokumentiere die <strong>Grenzwerte<\/strong>.<\/p>\n\n<h2>Keep-Alive, HTTP\/2 und Thread-Contention<\/h2>\n\n<p>Keep-Alive reduziert TCP-Handshakes, kann aber Threads binden \u2013 besonders beim Worker-MPM, das Verbindungen direkt auf Threads legt. Event l\u00f6st genau diesen Effekt, indem es die Verbindung \u00fcber einen Event-Loop <strong>abwickelt<\/strong> und Threads nur f\u00fcr aktive Arbeit nutzt. F\u00fcr HTTP\/2 setze ich deshalb Worker oder Event ein, weil Multiplexing sonst ausgebremst wird. In der Praxis beobachte ich gern die Warteschlangenl\u00e4nge und pr\u00fcfe, ob sich \u201eThread-Contention\u201c bemerkbar macht. Tipps dazu habe ich im Beitrag zu <a href=\"https:\/\/webhosting.de\/thread-contention-webserver-performance-boost-cache\/\">Thread-Contention<\/a> zusammengefasst, den ich f\u00fcr tiefergehende Analysen heranziehe.<\/p>\n\n<p>Ich passe au\u00dferdem KeepAliveTimeout an die Anwendung an, damit inaktive Verbindungen die <strong>Kapazit\u00e4t<\/strong> nicht binden. Die ideale Einstellung unterscheidet sich zwischen APIs, klassischen LAMP-Seiten und HTTP\/2-basierten Frontends mit vielen Assets. Kommt viel Leerlauf vor, senke ich den Timeout und erh\u00f6he MaxRequestWorkers leicht. Erwarte ich viele kurze Requests, halte ich Keep-Alive moderat, um TCP-Overhead zu sparen. Treten Wartezeiten auf, wechsle ich auf Event oder r\u00fcste zus\u00e4tzliche <strong>Instanzen<\/strong> nach.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/apache_worker_modelle_vergleich_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Praxis-Szenarien und Wahl des richtigen Modells<\/h2>\n\n<p>F\u00fcr Legacy-Apps mit riskanten Modulen setze ich Prefork ein und profitiere von hoher <strong>Abschirmung<\/strong>. Bei moderner PHP-FPM-Architektur mit vielen gleichzeitigen Verbindungen liefert Worker schon sehr gute Ergebnisse. Event dr\u00fcckt die Latenz weiter und skaliert sauber bei langen Sessions, WebSockets und HTTP\/2. Auf Shared-Hostings oder bei unklarem Code-Stand fahre ich mit Prefork sicherer, w\u00e4hrend ich auf VPS und dedizierter Hardware meist Event bevorzuge. Wer Alternativen zu Apache abw\u00e4gt, findet im kompakten <a href=\"https:\/\/webhosting.de\/webserver-vergleich-apache-nginx-litespeed-perfopt-serverboost\/\">Webserver-Vergleich<\/a> zus\u00e4tzliche Entscheidungshilfen zu Nginx und LiteSpeed, die ich situativ pr\u00fcfe.<\/p>\n\n<p>Bei Traffic-Spitzen mit Burst-Charakter zahlt sich Event aus, da Threads nicht in Leerlauf <strong>verharren<\/strong>. F\u00fcr CPU-lastige Apps limitiere ich MaxRequestWorkers, um die Maschine nicht zu \u00fcberbuchen. Steht RAM knapp, verbanne ich Prefork und priorisiere Worker\/Event. Bei Multi-Tenant-Umgebungen trennen Container oder cgroups die Services, sodass Worker\/Event ihr Potenzial entfalten. Am Ende best\u00e4tigt die Messung, welches Modell im eigenen Stack die geringste <strong>Latenz<\/strong> liefert.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/apacheworker-vergleich-6184.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Konfiguration auf Ubuntu\/Debian in der Praxis<\/h2>\n\n<p>Ich aktiviere und deaktiviere MPMs gezielt, teste die Auswirkung und halte Rollback-Optionen <strong>bereit<\/strong>. Unter Debian\/Ubuntu nutze ich die bekannten Kommandos und pr\u00fcfe anschlie\u00dfend die Statusausgabe. Danach feile ich an den mpm_*.conf-Dateien und protokolliere \u00c4nderungen versioniert. Vor dem Go-Live lasse ich Lastspitzen simulieren, um Deadlocks oder Speicherengp\u00e4sse fr\u00fch zu erkennen. Erst wenn Fehlerz\u00e4hler und Perzentile stimmen, \u00fcbernehme ich die <strong>Werte<\/strong> in Produktion.<\/p>\n\n<pre><code># Prefork einschalten\na2dismod mpm_worker mpm_event\na2enmod mpm_prefork\nsystemctl restart apache2\n\n# Worker einschalten\na2dismod mpm_prefork mpm_event\na2enmod mpm_worker\nsystemctl restart apache2\n\n# Event einschalten\na2dismod mpm_prefork mpm_worker\na2enmod mpm_event\nsystemctl restart apache2\n\n# Monitoring\napachectl status\nhtop\njournalctl -u apache2 -f\n<\/code><\/pre>\n\n<p>Ich beobachte parallel Fehler-Logs, um Thread-Sicherheitsprobleme rasch zu <strong>finden<\/strong>. F\u00fcr HTTP\/2 pr\u00fcfe ich, ob das Protokoll korrekt aushandelt und die TLS-Konfiguration passt. Bei auff\u00e4lligen Latenzen vergleiche ich Prefork\/Worker\/Event im Wechsel und behalte die RAM-Entwicklung im Blick. Stimmt die Balance nicht, passe ich KeepAlive, Threadanzahl und Limits an. So erreiche ich verl\u00e4ssliche Antwortzeiten ohne <strong>\u00dcberbuchung<\/strong>.<\/p>\n\n<h2>Thread-Sicherheit und Modul-Kompatibilit\u00e4t<\/h2>\n<p>Die wichtigste Vorpr\u00fcfung vor dem Wechsel von Prefork zu Worker\/Event ist die <strong>Thread-Sicherheit<\/strong> aller Module. Klassiker: mod_php ist historisch eng mit Prefork verkn\u00fcpft; in modernen Stacks setze ich stattdessen PHP-FPM via proxy_fcgi ein, damit Apache selbst threadbasiert skalieren kann. Auch Filter- und Auth-Module, selbstgeschriebene Module oder Integrationen (z. B. Bildverarbeitung) m\u00fcssen als \u201ethread safe\u201c gelten. Ich pr\u00fcfe die geladenen Module, werte Release-Notes aus und f\u00fchre unter Last einen Crash- und Race-Condition-Test durch. F\u00fcr HTTP\/2 gilt: Mit Prefork ist es praktisch keine Option \u2013 Worker\/Event sind die <strong>Voraussetzung<\/strong>, damit Multiplexing und Priorisierung wirken.<\/p>\n\n<h2>Kapazit\u00e4tsplanung: Speicherbudget realistisch kalkulieren<\/h2>\n<p>Ich dimensioniere MaxRequestWorkers nicht \u201egef\u00fchlt\u201c, sondern anhand messbarer Prozess- und Thread-Gr\u00f6\u00dfen. Vorgehen:<\/p>\n<ul>\n  <li>Testlast fahren, dann die Resident-Set-Size (RSS) pro Apache-Prozess messen.<\/li>\n  <li>Bei Worker\/Event den pro Thread zus\u00e4tzlichen Overhead ber\u00fccksichtigen.<\/li>\n  <li>Puffer f\u00fcr Kernel, Page Cache, TLS-Session-Cache, Log-Puffer und Upstreams einplanen.<\/li>\n<\/ul>\n<pre><code># Prozessgr\u00f6\u00dfe absch\u00e4tzen (Beispiel)\nps -ylC apache2 --sort:rss | awk '{sum+=$8} END {print \"RSS (kB) gesamt:\",sum}'\nps -L -p &lt;PID_eines_Apache-Kindprozesses&gt; -o pid,tid,psr,stat,rss,cmd\npmap -x &lt;PID&gt; | tail -n 1  # Gesamtsumme je Prozess\n<\/code><\/pre>\n<p>Rechenbeispiel: Ein Event-Prozess belegt 25 MB, Threads ben\u00f6tigen im Mittel 1 MB. Bei 16 Prozessen und 50 Threads ergibt das grob 16 \u00d7 25 MB + 800 \u00d7 1 MB \u2248 1,2 GB. Ich setze MaxRequestWorkers = 800, lasse 30\u201340 % RAM frei und skaliere nach Messung hoch. Wer Prefork einsetzt, rechnet einfach \u201eProzessgr\u00f6\u00dfe \u00d7 MaxRequestWorkers\u201c und bleibt <strong>konservativ<\/strong>.<\/p>\n\n<h2>Betriebssystem-Limits, Backlogs und Descriptoren<\/h2>\n<p>Apache kann nur so schnell sein wie die zugrunde liegende Plattform. Drei Punkte pr\u00fcfe ich regelm\u00e4\u00dfig:<\/p>\n<ul>\n  <li><strong>Dateideskriptoren:<\/strong> Ein Thread\/Prozess \u00f6ffnet Sockets, Dateien und Pipes. Ich erh\u00f6he LimitNOFILE \u00fcber systemd und verifiziere die \u00dcbernahme.<\/li>\n  <li><strong>Accept-Backlog:<\/strong> Bei Verbindungsbursts vergr\u00f6\u00dfere ich ListenBacklog und sorge f\u00fcr passende Kernel-Backlogs.<\/li>\n  <li><strong>Socket-\/Timeout-Tuning:<\/strong> RequestReadTimeout, Timeout und KeepAliveTimeout gezielt setzen, um \u201eSlow Clients\u201c zu entsch\u00e4rfen.<\/li>\n<\/ul>\n<pre><code># systemd-Override\nsystemctl edit apache2\n[Service]\nLimitNOFILE=65536\n\n# Kernel-Parameter (tempor\u00e4r)\nsysctl -w net.core.somaxconn=4096\n\n# Apache: Backlog und Timeouts\nListen 0.0.0.0:443\nListenBacklog 1024\nTimeout 60\nRequestReadTimeout header=10-20,MinRate=1 body=10,MinRate=500\nKeepAliveTimeout 5\nMaxKeepAliveRequests 100\n<\/code><\/pre>\n<p>Ich halte Timeouts lieber etwas strenger und beobachte die Fehlerraten. Werden legitime lange Uploads erwartet, passe ich Werte gezielt pro <strong>VirtualHost<\/strong> an.<\/p>\n\n<h2>Graceful Reloads, Deployments und Container<\/h2>\n<p>Im Betrieb bevorzuge ich Reloads ohne Abriss bestehender Verbindungen. <strong>apachectl -k graceful<\/strong> oder systemctl reload l\u00e4dt Konfigurationen neu, l\u00e4sst laufende Requests aber sauber auslaufen \u2013 bei Prefork pro Prozess, bei Worker\/Event pro Thread. In Container-Umgebungen plane ich kleinere ServerLimit\/ThreadsPerChild, damit Pods z\u00fcgig <strong>starten<\/strong> und beenden. Ich achte auf cgroup-Quotas: Werden CPU-Zeit oder RAM gekappt, muss MaxRequestWorkers entsprechend niedriger liegen, sonst verschiebt sich die Latenz in die 95.\/99.-Perzentile.<\/p>\n\n<h2>Proxy-\/Upstream-Setups richtig dimensionieren<\/h2>\n<p>Viele Apache-Instanzen terminieren TLS und proxien danach an PHP-FPM, App-Server oder Microservices. Dabei verkn\u00fcpfe ich Frontend-Kapazit\u00e4t (MaxRequestWorkers) mit den Upstream-Pools: F\u00fcr PHP-FPM sind pm.max_children und pm.max_requests die harte Obergrenze. Ich halte das Verh\u00e4ltnis so, dass Apache nicht wesentlich mehr gleichzeitige Anfragen annimmt, als Upstreams verarbeiten k\u00f6nnen \u2013 sonst entstehen Warteschlangen und <strong>Timeouts<\/strong>. F\u00fcr proxy_fcgi und proxy_http setze ich Timeouts explizit und pr\u00fcfe, ob Keep-Alive zum Upstream sinnvoll ist oder nur Ressourcen bindet.<\/p>\n\n<h2>Monitoring und Diagnose mit dem Scoreboard<\/h2>\n<p>Die mod_status-Ausgabe verr\u00e4t, wie gut das gew\u00e4hlte MPM arbeitet. Ich achte auf die Anteile folgender Zust\u00e4nde: <em>Reading<\/em> (eingehende Header), <em>Sending<\/em> (Antwort wird \u00fcbertragen), <em>Keepalive<\/em> (verbindungsoffen ohne Arbeit), <em>Waiting<\/em> (frei). Hohe Anteile von <em>Keepalive<\/em> bei Worker deuten auf gebundene Threads hin \u2013 Event beseitigt genau das. Dauerhaft <em>Reading<\/em> kann auf langsame Clients oder falsche <strong>RequestReadTimeout<\/strong>-Werte hindeuten. Viele <em>Closing\/Logging<\/em>-Zust\u00e4nde unter Spitzenlast sprechen f\u00fcr zu kleine Threadpools oder I\/O-Engp\u00e4sse im Logging.<\/p>\n\n<h2>Sicherheit und Robustheit: Slowloris &amp; Co.<\/h2>\n<p>Gegen \u201eSlowloris\u201c-artige Angriffsmuster hilft die Kombination aus Event-MPM, knappen KeepAliveTimeouts und RequestReadTimeout. Prefork sch\u00fctzt zwar durch Prozessisolierung vor Modulabst\u00fcrzen, bleibt aber anf\u00e4llig f\u00fcr RAM-<strong>Ersch\u00f6pfung<\/strong> bei vielen Verbindungen. Ich kombiniere Limits auf Webserver-Ebene mit vorgelagerten WAF\/Rate-Limits, damit Apache gar nicht erst mit Millionen halboffener Sessions konfrontiert wird. Logs werte ich auf 95.\/99.-Perzentile aus, weil Angriffe die Verteilungsschw\u00e4nze aufbl\u00e4hen.<\/p>\n\n<h2>Distribution-Defaults und typische Stolpersteine<\/h2>\n<p>Auf vielen Debian\/Ubuntu-Installationen ist Event heute Standard. Trotzdem sind Default-Werte oft konservativ (z. B. ThreadsPerChild 25\u201350). Ich erh\u00f6he diese erst nach Messung. H\u00e4ufige Fehler:<\/p>\n<ul>\n  <li>MaxRequestWorkers h\u00f6her als die verf\u00fcgbaren File-Deskriptoren.<\/li>\n  <li>Nicht synchronisierte Limits zwischen Apache und PHP-FPM\/App-Servern.<\/li>\n  <li>Zu hoher KeepAliveTimeout bei Worker mit vielen Mobil-Clients.<\/li>\n  <li>Fehlender Puffer f\u00fcr Log-I\/O \u2013 Rotationsjobs blockieren <strong>kurzzeitig<\/strong>.<\/li>\n<\/ul>\n<p>Ich dokumentiere Zielwerte (CPU-Auslastung, RAM, RPS, P95) und sichere die funktionierende Konfiguration versioniert. Erst dann erfolgt die <strong>Ausrollung<\/strong>.<\/p>\n\n<h2>Kurz zusammengefasst<\/h2>\n\n<p>Prefork liefert starke <strong>Isolation<\/strong> f\u00fcr Legacy-Stacks, kostet aber viel Speicher. Worker bietet eine gute Mitte mit Threads je Prozess und skaliert sauber, solange Keep-Alive nicht unn\u00f6tig bindet. Event trennt Verbindung und Bearbeitung, erh\u00f6ht die Auslastung und spielt seine St\u00e4rke bei HTTP\/2 sowie langen Sessions aus. Ich messe systematisch, passe Limits an und w\u00e4hle das MPM, das zum Code, zum Traffic-Profil und zur Hardware passt. Mit sauberem Tuning, klaren Messzielen und fokussiertem Monitoring holt Apache aus jedem der drei Modelle <strong>Leistung<\/strong> heraus.<\/p>","protected":false},"excerpt":{"rendered":"<p>Prefork\u3001Worker\u3001Event\u306a\u3069\u306eApache\u30ef\u30fc\u30ab\u30fc\u30e2\u30c7\u30eb\u306f\u3001Web\u30b5\u30fc\u30d0\u30fc\u306e\u30d1\u30d5\u30a9\u30fc\u30de\u30f3\u30b9\u3092\u6700\u9069\u5316\u3057\u307e\u3059\u3002\u5b8c\u5168\u306a\u6bd4\u8f03\u3068\u8a2d\u5b9a.<\/p>","protected":false},"author":1,"featured_media":18129,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-18136","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-plesk-webserver-plesk-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"936","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"Apache Worker Modelle","rank_math_og_content_image":{"check":"8fd1a44c0a2802f53fef8e6e30ccee29","images":[18130]},"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"18129","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/ja\/wp-json\/wp\/v2\/posts\/18136","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/ja\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/ja\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/ja\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/ja\/wp-json\/wp\/v2\/comments?post=18136"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/ja\/wp-json\/wp\/v2\/posts\/18136\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/ja\/wp-json\/wp\/v2\/media\/18129"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/ja\/wp-json\/wp\/v2\/media?parent=18136"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/ja\/wp-json\/wp\/v2\/categories?post=18136"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/ja\/wp-json\/wp\/v2\/tags?post=18136"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}