Entwickler müssen oft mitansehen, wie ihre gerade erst gestartete App ins Stocken gerät, sobald einige tausend Nutzer auf „Los“ klicken. Die Verlangsamung ist selten ein Fehler im Code – vielmehr kämpfen die CPU und der RAM des Servers um Ressourcen. Dieser Engpass äußert sich in längeren Ladezeiten, Timeouts oder völligen Abstürzen, was die Nutzererfahrung, den Umsatz und das Markenvertrauen schädigt.

Warum ein Server, der im Labor einwandfrei lief, in der Produktion zum Erliegen kommen kann

Während der Entwicklung sendet ein einzelner Entwickler nur eine Handvoll Anfragen, sodass die Ressourcen des Servers die meiste Zeit im Leerlauf sind. Wenn die App live geht, generiert jeder Besucher eine Anfrage, die zwei Kernkomponenten benötigt:

  • CPU (Central Processing Unit) – der Prozessor, der jede Schleife, jede Funktion und jede Berechnung ausführt. Stellen Sie sich die CPU wie einen Koch vor, der nur eine begrenzte Anzahl von Gerichten gleichzeitig zubereiten kann. Eine Bestellung wird sofort serviert; bei hundert Bestellungen arbeitet der Koch zwar immer noch gleich schnell, aber die Gäste müssen länger warten.
  • RAM (Random-Access Memory) – der temporäre Speicher für Daten, die die CPU während der Bearbeitung einer Anfrage benötigt. Er ist wie ein Schreibtisch, auf dem der Koch die Zutaten für jedes Gericht bereithält. Wenn der Schreibtisch voll ist, muss der Koch die Annahme neuer Bestellungen stoppen, bis wieder Platz geschaffen wurde.

Wenn sich tausende Nutzer gleichzeitig anmelden, beansprucht jede Anfrage ihren eigenen Anteil an der CPU-Zeit und ihren eigenen Block im RAM. Der begrenzte Pool beider Ressourcen wird auf die Anfragen aufgeteilt, und die Warteschlange wächst. Der Server selbst ist nicht langsamer geworden; die Wartezeit für jede einzelne Anfrage hat sich lediglich erhöht.

Die Versuchung, „einfach eine größere Kiste zu kaufen“

Eine häufige erste Reaktion ist es, die Maschine aufzurüsten – eine Praxis, die als vertikale Skalierung (vertical scaling) bezeichnet wird. Das Hinzufügen von mehr CPU-Kernen oder mehr RAM verbessert die Kapazität: Der Wechsel von 4 Kernen auf 16 oder von 8 GB auf 64 GB kann einen größeren Traffic-Anstieg abfangen, ohne dass der Code geändert werden muss.

Die vertikale Skalierung stößt jedoch an eine harte Grenze:

  • Physische Grenzen – jedes Mainboard kann nur eine bestimmte Anzahl von Kernen und eine begrenzte Menge an Arbeitsspeicher aufnehmen.
  • Sinkende Grenzerträge – jeder zusätzliche Kern oder jedes zusätzliche Gigabyte kostet mehr als das vorherige, während der Leistungsgewinn immer geringer wird.
  • Single Point of Failure – wenn der überdimensionierte Server ausfällt, ist der gesamte Dienst nicht mehr erreichbar.

Aufgrund dieser Einschränkungen sind die Schwergewichte der Branche – Streaming-Plattformen, Suchmaschinen, E-Commerce-Seiten – von einer einzelnen „Monster-Maschine“ Abstand gegangen.

Die Alternative: Die Last auf viele kleinere Kisten verteilen

Anstatt einen höheren Turm zu bauen, setzen Betreiber auf mehr Server moderater Größe und lassen diese die Last teilen. Dieser Ansatz der horizontalen Skalierung (horizontal scaling) hält jede Maschine in einem komfortablen Leistungsbereich und vermeidet die exponentielle Kostenkurve vertikaler Upgrades.

Die Koordination vieler Maschinen erfordert einen Load Balancer – eine Software oder Hardware, die jede eingehende Anfrage empfängt und sie an den Server mit der größten verfügbaren Kapazität weiterleitet. Der Balancer verbirgt die Komplexität vor dem Client; aus der Sicht des Nutzers sieht die Website weiterhin wie ein einziger Endpunkt aus.

Horizontale Skalierung bringt zudem Resilienz. Wenn ein Knoten ausfällt, leitet der Balancer den Datenverkehr einfach an die verbleibenden gesunden Knoten weiter, wodurch der Dienst aufrechterhalten wird.

Worauf Sie achten sollten, wenn Sie anfangen, Maschinen hinzuzufügen

  • Stateless Design – Anfragen sollten sich nicht auf Daten verlassen, die nur im Speicher eines spezifischen Servers gespeichert sind; andernfalls könnte ein Nutzer zu einem Knoten weitergeleitet werden, dem der nötige Kontext fehlt. Die Verwendung von gemeinsam genutzten Caches oder Datenbanken löst dieses Problem.
  • Health Checks – der Balancer muss in der Lage sein, einen ausfallenden Server schnell zu erkennen und aufzuhören, Datenverkehr an ihn zu senden.
  • Auto-Scaling-Richtlinien – viele Cloud-Plattformen ermöglichen es Ihnen, Schwellenwerte (CPU-Auslastung, Anfrage-Latenz) zu definieren, die automatisch Instanzen hochfahren oder herunterfahren, um die Kosten an die Nachfrage anzupassen.

Gegenargument: Vertikale Skalierung ist nicht tot

Für kleine Teams oder Apps mit geringem Traffic kann ein einzelner, leistungsstarker Server die einfachste und günstigste Lösung sein. Wenn der Traffic-Anstieg vorhersehbar ist (z. B. ein geplanter Produktlaunch), kann ein temporäres vertikales Upgrade praktischer sein, als eine ganze Flotte neuer Instanzen bereitzustellen.

Der entscheidende Punkt ist zu erkennen, wann der Trick mit der „größeren Kiste“ keinen proportionalen Nutzen mehr bringt, und mit der Planung einer Verteilung zu beginnen.

Fazit

Eine Verlangsamung des Servers nach dem Launch ist in der Regel ein Problem der Ressourcenkonkurrenz (Resource Contention) und kein Code-Defekt. CPU-Zyklen und RAM-Kapazitäten sind begrenzt, und wenn viele Anfragen gleichzeitig eintreffen, stauen sie sich in Warteschlangen an, was die Antwortzeiten verlängert. Vertikales Skalieren verschafft Ihnen etwas mehr Spielraum, stößt aber bald an physische und wirtschaftliche Grenzen. Horizontales Skalieren – das Hinzufügen von bescheideneren Servern hinter einem Load Balancer – bietet einen kostengünstigeren und resilienteren Weg, wenn der Traffic wächst. Sobald Sie bemerken, dass die Warteschlangen länger werden, ist es an der Zeit zu prüfen, ob ein paar zusätzliche Kerne ausreichen oder ob Sie damit beginnen sollten, die Last auf viele Maschinen zu verteilen.

Quelle: dev.to Artikel „Why Servers Slow Down – CPU, RAM and the hidden cost of every request.“