Website überlastet? So verhindern Sie Abstürze bei Kampagnen

Wie verhindern Sie, dass Ihre Website überlastet ist, wenn eine Kampagne startet?

Eine Website ist überlastet, wenn ein plötzlicher Besucheransturm Prozessor, Arbeitsspeicher, PHP Prozesse oder die Datenbank des Servers erschöpft und Seiten nicht mehr laden. Dagegen helfen Caching und ein CDN, schnellere Datenbankabfragen, ein Lasttest, eine Überwachung mit Alarmen und, falls nötig, mehr Hostingkapazität vor dem Kampagnenstart.

Wir sind Talha Aslan und Team, ein Team für digitales Marketing und Webentwicklung. Ein Hostinganbieter sind wir allerdings nicht. Deshalb stützen wir Einstellungen und Befehle in diesem Ratgeber auf die offiziellen Dokumentationen von PHP, MySQL, nginx, MDN und Google Search Central. Unser Ziel: Shopbetreiber und Entwickler mit eigenem VPS sollen wissen, was sie in welcher Reihenfolge tun.

Wie Sie aus Besucherzahlen eine Kapazität berechnen, behandeln wir in einem eigenen Beitrag. Hier geht es stattdessen um das Vorbeugen: Ursachen, Reihenfolge der Maßnahmen, Tests, Überwachung, Rückfallplan und eine Checkliste für den Kampagnentag.

Warum bringt Kampagnentraffic eine Website zum Absturz?

An einem normalen Tag verteilen sich die Besucher über viele Stunden. Eine Kampagne ändert das allerdings. Ein Newsletter, eine Pushnachricht, der Start eines Flash Sale oder der Beitrag einer Influencerin schickt sehr viele Menschen in denselben Minuten auf Ihre Seite. Für den Server zählt dann nicht die Tagessumme, sondern die Zahl gleichzeitiger Anfragen.

Jede Anfrage belegt eine Ressource: einen PHP Prozess, eine Datenbankverbindung, etwas Arbeitsspeicher. Sind diese Ressourcen aufgebraucht, reihen sich neue Anfragen in eine Warteschlange ein. Mit der Schlange steigen dann die Antwortzeiten. Danach folgen Zeitüberschreitungen und Fehler wie 502, 503 oder 504. Kurz gesagt: Ist eine Website überlastet, fällt sie selten schlagartig aus; zunächst wird sie langsam, dann häufen sich die Fehler.

Zudem landet Kampagnentraffic auf den teuersten Seiten. Warenkorb, Kasse, Suche und Filter sind personalisiert und umgehen den Seitencache. Folglich belastet jeder Besucher direkt die Datenbank. Außerdem sind Besucher aus Anzeigen ungeduldig. Hängt eine Seite einige Sekunden, springen sie ab, und den Klick bezahlen Sie trotzdem.

Welche Engpässe führen dazu, dass eine Website überlastet ist?

Ein Absturz hat selten nur eine Ursache. Meist reißt zunächst das schwächste Glied der Kette. Die Tabelle fasst die häufigsten Engpässe, ihre Symptome und die erste Maßnahme vor einer Kampagne zusammen.

Beim Shared Hosting hat zudem Ihr Tarif eigene Grenzen für CPU, Speicher, I/O und gleichzeitige Prozesse. Ihre Seite kann also Fehler liefern, obwohl der physische Server noch Reserven hat. Fragen Sie deshalb Ihren Anbieter rechtzeitig nach den Limits Ihres Tarifs.

Warum stoßen PHP Prozesse meist zuerst an ihre Grenze?

Bei PHP Seiten wie WordPress, WooCommerce oder Laravel belegt jede dynamische Anfrage einen Prozess von PHP-FPM. Laut PHP Handbuch legt pm.max_children die Grenze für gleichzeitig bediente Anfragen fest. Sind alle Prozesse beschäftigt, wartet der nächste Besucher also.

Der erste Reflex ist daher, diesen Wert zu erhöhen. Allerdings verbraucht jeder Prozess Arbeitsspeicher. Übersteigt die Zahl der Prozesse mal dem Speicher pro Prozess den freien Speicher, lagert der Server auf Swap aus und bremst noch stärker. Daher senken Sie zuerst die Last pro Anfrage und passen erst dann die Prozessanzahl an den Speicher an.

; PHP-FPM Pooldatei, Beispielgerüst
pm = dynamic
pm.max_children = (nach Ihrer Speicherrechnung)
pm.max_requests = (gegen Speicherlecks)
pm.status_path = /fpm-status

Das Handbuch beschreibt pm.max_requests als Zahl der Anfragen, nach denen ein Prozess neu startet; das hilft gegen Speicherlecks in Bibliotheken von Drittanbietern. pm.status_path öffnet eine Statusseite. Somit sehen Sie während der Kampagne, wie viele Prozesse arbeiten. Geben Sie diese Statusseite nur für Ihre eigene IP frei.

In welcher Reihenfolge schützen Sie eine Website, die überlastet sein könnte?

Die Reihenfolge zählt, denn günstige und wirksame Maßnahmen kommen vor teuren. Ein größerer Server für eine schlecht gebaute Seite verschiebt das Problem also nur. Wir empfehlen diese Abfolge:

1. Seitencache und Objektcache aktivieren, personalisierte Seiten ausnehmen.
2. Statische Dateien über ein CDN mit langen Cachezeiten ausliefern.
3. Bilder und JavaScript verschlanken, unnötige Tags von Drittanbietern entfernen.
4. Langsame Datenbankabfragen finden und fehlende Indizes ergänzen.
5. Die Landingpage der Kampagne vereinfachen und Livezähler cachen.
6. Bei Bedarf einen Warteraum oder eine Begrenzung der Anfragerate planen.
7. Einen Lasttest auf einer Stagingkopie durchführen.
8. Überwachung und Alarme einrichten.
9. Ein Backup erstellen und den Rückfallplan aufschreiben.
10. Hostingkapazität nach den Testergebnissen vorab erhöhen.
11. Werbe- und Newsletterplanung mit dem Technikteam abstimmen.

Beginnen Sie mit dieser Liste mindestens einige Wochen vor der Kampagne. Rutschen Test und Kapazitätserhöhung auf den letzten Tag, bleibt keine Zeit mehr für Korrekturen.

Wie entlasten Seitencache und Objektcache den Server?

Ein Seitencache speichert das fertige HTML einer Seite und liefert es dem nächsten Besucher aus, ohne PHP oder die Datenbank anzufassen. Kampagnenseiten, Produktseiten und Kategorien sehen für alle gleich aus; sie belasten den Server dann kaum. Bei WordPress übernimmt das ein Cache Plugin, auf Serverebene etwa Varnish oder der Cache von nginx.

Ein Objektcache hält Ergebnisse von Datenbankabfragen im Arbeitsspeicher. Somit brauchen selbst personalisierte Seiten weniger Abfragen. Den Unterschied zwischen Redis und Memcached erklären wir in Caching erklärt: Redis und Memcached. Prüfen Sie außerdem Ihre OPcache Einstellungen, damit PHP den Code nicht bei jeder Anfrage neu übersetzt.

Allerdings hat Caching zwei Fallen. Erstens: Landen Warenkorb, Kasse oder Kundenkonto im Cache, sieht ein Kunde womöglich die Daten eines anderen; nehmen Sie diese Seiten deshalb immer aus. Zweitens kann beim Start der Aktion noch der alte Preis im Cache stehen. Legen Sie daher vorab fest, wie und in welcher Reihenfolge Sie den Cache zum Start leeren.

Was bringt es, statische Inhalte über ein CDN auszuliefern?

Beim Laden einer Seite gehen die meisten Anfragen an Bilder, CSS, JavaScript und Schriften. Zudem sind diese Dateien für alle Besucher gleich. Ein CDN liefert sie von Servern in der Nähe des Besuchers aus. Ihr eigener Server kümmert sich dann nur noch um dynamische Anfragen.

Dafür brauchen Sie passende Cache-Control Header. MDN empfiehlt für statische Dateien mit Version oder Hash im Dateinamen dieses Muster:

Cache-Control: max-age=31536000, immutable

Laut derselben Seite gilt s-maxage nur für geteilte Caches wie ein CDN. Mit stale-if-error darf ein Cache zudem eine veraltete Antwort ausliefern, wenn der Ursprungsserver 500, 502, 503 oder 504 meldet. Während einer Kampagne kann diese Anweisung einen kurzen Aussetzer vor Besuchern verbergen. Prüfen Sie dennoch in der Dokumentation Ihres CDN, ob es die Anweisung unterstützt.

Schließlich gilt: Erfordert das CDN eine Änderung am DNS, nehmen Sie sie Tage vor der Kampagne vor. Die Verbreitung im DNS und ein neues SSL Zertifikat brauchen Zeit.

Wie reduzieren Sie Bilder und JavaScript vor einer Kampagne?

Je schwerer eine Seite ist, desto mehr Arbeit haben Server und Netz bei gleichem Traffic. Außerdem verliert eine langsame Seite genau die Besucher, für die Sie bezahlt haben. Wie die Ladezeit die Sichtbarkeit beeinflusst, zeigen wir in Wie beeinflusst die Ladezeit SEO. Den Einfluss auf den Umsatz behandeln wir in Ladezeit im Onlineshop.

Schnelle Erfolge vor einer Kampagne sind zum Beispiel:

• Bilder in moderne Formate umwandeln und in echter Anzeigegröße ausliefern.
• Lazy Loading für Bilder unterhalb des sichtbaren Bereichs nutzen.
• Ungenutzte Plugins und Blöcke von Seitenbaukästen entfernen.
• Tags von Drittanbietern wie Livechat, Heatmaps und doppelte Pixel reduzieren.
• Auf der Kampagnenseite auf automatisch startende Videos und schwere Slider verzichten.

Was Sie bei Skripten aufschieben oder entfernen, erklärt unser Ratgeber JavaScript Ladezeit optimieren. Messen Sie dann nach jeder Änderung erneut. In der Praxis entscheiden Ergebnisse, nicht Vermutungen.

Wie prüfen Sie Datenbankabfragen und Indizes?

Warenkorb, Kasse und Suche umgehen den Cache und greifen direkt auf die Datenbank zu. Vor allem unter Last kann eine einzige langsame Abfrage alle Verbindungen blockieren. Deshalb suchen Sie langsame Abfragen vor der Kampagne, nicht währenddessen.

Die MySQL Dokumentation zeigt, wie Sie das Slow Query Log zur Laufzeit einschalten:

SET GLOBAL slow_query_log = 1;
SET GLOBAL long_query_time = 2;
SET GLOBAL log_queries_not_using_indexes = 1;

Der Schwellenwert ist nur ein Beispiel; wählen Sie einen passenden Wert für Ihre Seite. Laut Dokumentation fasst das Werkzeug mysqldumpslow lange Logdateien zusammen und zeigt die häufigsten langsamen Abfragen. Danach prüfen Sie verdächtige Abfragen mit EXPLAIN und sehen, ob ein Index greift.

Eine weitere Quelle für Sperren sind geplante Aufgaben. Ein Lagerimport, ein Berichtsexport oder eine Massenänderung von Preisen kann Tabellen sperren, wenn sie im Kampagnenfenster läuft. Verschieben Sie solche Cronjobs also aus dem Zeitfenster. Haben Sie im Shared Hosting keinen Zugriff auf diese Befehle, bitten Sie Ihren Anbieter um einen Bericht über langsame Abfragen.

Wie können externe Dienste dazu führen, dass die Website überlastet ist?

Auch ein gesunder Server kann wegen eines externen Dienstes hängen. Zahlungsanbieter, Versandkostenberechnung, SMS Verifizierung, Rechnungsstellung oder Lagerabgleich werden unter Kampagnenlast manchmal langsam. Jede Anfrage, die auf sie wartet, blockiert einen PHP Prozess. Irgendwann sind alle Prozesse belegt und die Website überlastet; Besucher sehen dann eine Fehlerseite, obwohl die Ursache woanders liegt.

Dagegen gibt es konkret drei Maßnahmen. Erstens geben Sie jedem externen Aufruf ein kurzes, klares Timeout, damit ein hängender Dienst keine Anfrage endlos festhält. Zweitens schieben Sie Bestellbestätigungen, Rechnungen und Benachrichtigungen in eine Warteschlange im Hintergrund. So antwortet die Kasse schnell.

Drittens nehmen Sie die Statusseiten Ihrer wichtigsten Dienstleister in die Überwachung am Kampagnentag auf. Außerdem lohnt es sich, Zahlungs- und Versanddienstleister über den Kampagnentermin zu informieren. Kurz gesagt: Eine Vorbereitung, die ein Glied der Kette übersieht, bleibt unvollständig.

Wie halten Sie die Landingpage der Kampagne schlank?

Die Landingpage fängt den ersten Ansturm ab. Sie sollte daher cachefähig, schlicht und frei von personalisierten Blöcken sein. Sehen alle Besucher denselben Inhalt, kommt die Seite direkt aus dem Cache oder dem CDN.

Häufige Fehler sind ein Live Lagerzähler mit Datenbankabfrage bei jedem Aufruf, eine Box mit aktuellen Betrachtern, personalisierte Empfehlungen und ein Countdown auf Basis der Serverzeit. Lassen Sie den Countdown stattdessen im Browser gegen eine feste Endzeit laufen. Lagerbestände zeigen Sie über einen kurzlebigen Cache an.

Leiten Sie Anzeigen außerdem nicht auf Such- oder Filterergebnisse. Diese Seiten starten für jede Kombination eine andere Abfrage. Nutzen Sie stattdessen eine gecachte Kampagnenseite oder Kategorieseite. Auch der Schritt in den Warenkorb sollte mit einer möglichst leichten Anfrage auskommen.

Formulare und Tracking erzeugen ebenfalls Last. Zum Beispiel bedeutet eine zusätzliche Serveranfrage pro Seitenaufruf in der Spitze Tausende zusätzliche Vorgänge. Halten Sie Formulare schlicht, bündeln Sie das Tracking im Tag Manager und messen Sie im Test die Dauer jeder Anfrage. Prüfen Sie dann die mobile Ansicht gesondert, denn ein großer Teil des Kampagnentraffics kommt meist vom Smartphone.

Wann sind ein Warteraum und eine Begrenzung der Anfragerate sinnvoll?

Ein Warteraum hält Besucher oberhalb Ihrer Kapazität auf einer leichten Seite und lässt sie nach und nach hinein. Das passt zu Ticketverkäufen oder limitierten Produkten, bei denen alle in derselben Sekunde kommen. Somit können Käufer, die schon im Shop sind, ihren Kauf abschließen, und die Seite bricht nicht zusammen.

Einfacher ist eine Begrenzung der Anfragerate. Das Beispiel in der nginx Dokumentation begrenzt Anfragen einer Adresse auf eine feste Rate:

limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
location /search/ {
    limit_req zone=one burst=5;
}

Laut Dokumentation erhalten abgelehnte Anfragen standardmäßig die Antwort 503. Setzen Sie die Regel also nur bei teuren Endpunkten wie der Suche ein, nicht für die gesamte Seite. Sonst sperren Sie auch echte Kunden aus.

Müssen Sie einen Teil der Seite vorübergehend abschalten, empfiehlt Google Search Central, Funktionen einzuschränken statt die Seite komplett zu schließen. Für kurze Ausfälle nennt Google den Statuscode 503 mit dem Header retry-after und rät, diesen Zustand nicht länger als ein bis zwei Tage zu halten.

Wie und wo führen Sie einen Lasttest durch?

Ein Lasttest simuliert den Kampagnentraffic im Voraus. Dadurch sehen Sie, ab wann Ihre Website überlastet ist und wo sie hakt. Mit Open Source Werkzeugen wie Apache JMeter, k6 oder Locust bilden Sie eine echte Besucherreise ab: Startseite, Kampagnenseite, Produkt, Warenkorb.

Belasten Sie Ihre Liveseite allerdings nicht ohne Erlaubnis. Im Shared Hosting trifft ein schwerer Test die Nachbarseiten, und Ihr Anbieter hält ihn womöglich für einen Angriff und sperrt Ihre IP. Sicherer ist dieses Vorgehen:

• Eine Stagingkopie mit denselben Einstellungen wie die Liveseite aufbauen.
• Muss der Test live laufen, den Anbieter schriftlich informieren und ein Zeitfenster vereinbaren.
• Die Last schrittweise steigern, statt mit einer plötzlichen Spitze zu beginnen.
• Antwortzeit, Fehlerquote und Serverressourcen gleichzeitig aufzeichnen.
• Gecachte Seiten und ungecachte Schritte wie den Warenkorb getrennt testen.

Ziel ist keine Rekordzahl. Vielmehr suchen Sie den Bruchpunkt und die Ressource, die zuerst ausgeht. Sind zum Beispiel die Prozesse voll, kehren Sie zum Caching zurück; wartet die Datenbank, zu den Abfragen. Dann beheben Sie das Problem und testen erneut.

Wann und wie erhöhen Sie die Hostingkapazität?

Zeigt der Test auch nach den Softwaremaßnahmen, dass die Website überlastet ist, kommt mehr Hardware an die Reihe. Im Shared Hosting bedeutet das meist einen höheren Tarif, beim VPS mehr CPU und Arbeitsspeicher. Den Wechsel ohne Unterbrechung beschreiben wir in Hostingtarif upgraden ohne Ausfall.

VPS, VDS und Cloud Server samt Kapazitätsplanung für Kampagnen vergleichen wir in VPS oder Cloud Server; hier wiederholen wir das nicht. Kurz gesagt eignen sich Cloud Server besser für vorübergehendes Skalieren, feste Tarife bieten dagegen planbarere Kosten.

Der Zeitpunkt ist entscheidend. Erhöhen Sie die Kapazität vor dem Lasttest, nicht am Kampagnentag, damit Sie auch die neue Kapazität messen. Fragen Sie zudem Ihren Anbieter, ob Sie nach der Kampagne zurückstufen können und ob das eine Unterbrechung erfordert. Steht ein Serverumzug an, senken Sie die TTL im DNS frühzeitig.

Welche Kennzahlen überwachen Sie, damit Ihre Website nicht unbemerkt überlastet ist?

Ohne Überwachung erfahren Sie erst durch verärgerte Kunden, dass Ihre Website überlastet ist. Behalten Sie vor der Kampagne mindestens diese Werte im Blick:

• Verfügbarkeit: ein Monitor, der die Seite von mehreren externen Standorten prüft.
• Antwortzeit, vor allem für Kampagnenseite und Warenkorb.
• Fehlerquote: der Anteil der 5xx Antworten an allen Anfragen.
• Serverlast: CPU, Arbeitsspeicher und Swap.
• Aktive Prozesse auf der Statusseite von PHP FPM.
• Datenbankverbindungen und Anzahl langsamer Abfragen.
• Belegter Speicherplatz, denn Logdateien wachsen unter Last schnell.

Wie Sie Lastwerte richtig lesen, erklärt Load Average unter Linux richtig deuten. Legen Sie Alarmschwellen nach Ihren eigenen normalen Tagen fest, nicht nach fremden Zahlen. Ein Alarm sollte etwa auslösen, wenn die Antwortzeit deutlich über dem üblichen Niveau liegt. Für eine schnelle Prüfung von außen nutzen Sie unser Werkzeug Ist die Seite down. Schließlich halten Sie schriftlich fest, wer nachts Alarme erhält und was diese Person allein entscheiden darf.

Wie bereiten Sie Backup und Rückfallplan vor?

Die Kampagnenwoche ist keine Woche für Änderungen. Beschließen Sie deshalb einige Tage vorher einen Änderungsstopp für Code und Plugins. Updates für Theme, Plugins und Kern spielen Sie erst nach der Kampagne ein.

Danach erstellen Sie ein vollständiges Backup und testen die Wiederherstellung. Ein Backup, das sich nicht zurückspielen lässt, ist kein Backup. Backuparten und Aufbewahrung erklären wir in unserer Website Backup Strategie. Achten Sie zudem darauf, dass keine Sicherung im Kampagnenfenster läuft, weil Backups Festplatte und CPU stark belasten.

Ihr Rückfallplan braucht drei Dinge. Erstens die Schritte zurück zur letzten funktionierenden Version. Zweitens Schalter, mit denen Sie schwere Funktionen wie Empfehlungen oder Livesuche mit einer Einstellung abschalten. Drittens eine leichte Hinweisseite mit Status 503 und einen kurzen Statustext für Social Media. Ist die Website überlastet, folgen Sie so einem fertigen Plan, statt zu improvisieren.

Wie stimmen Sie Werbebudget und Landingpage mit der Technik ab?

Laufen technische Vorbereitung und Werbeplan getrennt, entsteht der teuerste Fehler: Das Werbebudget fließt pro Klick weiter, während die Website überlastet ist und kaum noch reagiert. Deshalb sollten Werbeteam und Technikteam mit demselben Kalender arbeiten.

Konkret versenden Sie den Newsletter in Etappen statt an alle auf einmal. Pushnachrichten teilen Sie in Gruppen auf. Das Werbebudget erhöhen Sie schrittweise, während Sie die Reaktion der Seite beobachten. Versehen Sie außerdem jeden Kanal mit UTM Parametern; so sehen Sie sofort, welcher Kanal die Spitze auslöst.

Legen Sie vorab fest, was passiert, wenn die Seite langsam wird. Welche Kampagnen drosseln Sie, welche pausieren Sie, und wer gibt die Freigabe? Kampagnen in Google Ads oder Meta pausieren Sie mit wenigen Klicks; eine Diskussion mitten in der Krise kostet dagegen Zeit. Diese Abstimmung behandeln wir als Teil der Kampagnenplanung in unserer Google Ads Verwaltung.

Welche Aufgaben überlassen Sie besser Ihrem Hostinganbieter?

Ehrlich gesagt müssen Sie nicht jede Maßnahme selbst umsetzen. Im Shared Hosting haben Sie ohnehin keinen Zugriff auf die Einstellungen von PHP FPM, Webserver oder Datenbank; dafür ist der Anbieter zuständig. Ihr Bereich ist in diesem Fall die Seite selbst: Cache Plugin, Bilder, Plugins und Kampagnenseite.

Bei einem verwalteten VPS passen Sie Servereinstellungen gemeinsam mit dem Anbieter an. Auch mit eigenem Server gilt: Ist Ihre Erfahrung mit Linux und Webservern begrenzt, ändern Sie kurz vor der Kampagne keine Konfigurationsdateien. Eine falsche Einstellung legt die Seite lahm, noch bevor Traffic kommt.

Schutz vor Angriffen auf Netzebene, Kapazität im Rechenzentrum und Hardwaredefekte liegen in jedem Fall beim Anbieter. Informieren Sie ihn schriftlich über Kampagnentermin, erwartete Spitze und geplanten Lasttest. Folglich erhalten Sie im Ernstfall schneller Unterstützung.

Wann holen Sie sich also Hilfe von außen? Etwa dann, wenn der Lasttest einen Bruchpunkt zeigt, den Sie nicht erklären können, wenn Logs unverständliche Fehler enthalten oder wenn wenige Tage vor dem Start ein großer Umbau nötig ist. Andererseits lösen Webteams Aufgaben rund um Ladezeit und Landingpage meist gut selbst.

Checkliste für den Kampagnentag, wenn die Website überlastet sein könnte

Gehen Sie am Morgen der Kampagne diese Punkte der Reihe nach durch. Teilen Sie die Liste mit dem ganzen Team und geben Sie jedem Punkt eine verantwortliche Person.

• Der Cache ist aktiv und zeigt die Aktionspreise korrekt.
• Warenkorb, Kasse und Kundenkonto bleiben außerhalb des Caches.
• Das CDN läuft und liefert die statischen Dateien aus.
• Der Änderungsstopp für Code und Plugins gilt.
• Ein aktuelles Backup liegt vor, die Schritte zur Wiederherstellung sind griffbereit.
• Alarme für Verfügbarkeit, Antwortzeit und Fehlerquote sind aktiv.
• Schwere Cronjobs und Backups laufen außerhalb des Kampagnenfensters.
• Eine Testbestellung hat Zahlung und Versandanbindung bestätigt.
• Reihenfolge von Anzeigen und Newsletter passt zum Plan der Technik.
• Hinweisseite und Statustext liegen bereit.
• Supportkanal des Anbieters und Kontaktliste sind zur Hand.

Jeder Punkt ist die letzte Kontrolle einer Maßnahme aus den Abschnitten oben. Anders gesagt ersetzt die Checkliste die Vorbereitung nicht.

Was tun Sie zuerst, wenn die Seite während der Kampagne langsam wird?

Trotz guter Vorbereitung kann eine unerwartete Verlangsamung auftreten. Folgen Sie dann einer vorab notierten Reihenfolge statt in Hektik zu geraten. Dadurch wird aus einer kurzen Verlangsamung kein kompletter Ausfall.

1. Zunächst das Problem bestätigen: Zeigen externe Prüfung, Antwortzeit und Fehlerquote dasselbe Bild?
2. Danach die erschöpfte Ressource finden: Prozesse, Arbeitsspeicher oder Datenbank?
3. Schwere, aber verzichtbare Funktionen abschalten: Livesuche, Empfehlungen, Filter.
4. Prüfen, ob der Cache wirklich greift und die Kampagnenseite aus dem Cache kommt.
5. Werbebudgets drosseln oder verbleibende Newsletteretappen zurückhalten.
6. Bessert sich nichts, den Hostinganbieter kontaktieren und bei Bedarf die Hinweisseite aktivieren.

Notieren Sie jeden Schritt mit Uhrzeit. Dann sehen Sie in der Auswertung genau, was gewirkt hat.

Was werten Sie nach dem Ende der Kampagne aus?

Nach der Kampagne lohnt sich eine kurze Auswertung, solange die Erinnerung frisch ist. Legen Sie Servergrafiken, Fehlerlogs und Werbedaten nebeneinander. So fällt die Vorbereitung der nächsten Aktion deutlich leichter.

Suchen Sie Antworten auf diese Fragen: Wann kam die höchste gleichzeitige Last, und welcher Kanal hat sie ausgelöst? Ab wann stieg die Antwortzeit, und welche Ressource ging zuerst aus? Welcher Alarm hat geholfen, welcher nur gestört? Ist Werbebudget verpufft, während die Seite langsam war?

Danach planen Sie, die zusätzliche Kapazität zurückzufahren, den Änderungsstopp aufzuheben und ausstehende Updates kontrolliert einzuspielen. Somit verläuft jede Kampagne ruhiger als die vorige, und das Risiko, dass Ihre Website überlastet ist, sinkt weiter.