Wie wir eine Nachrichtenseite auf eine Lastspitze vorbereiten.
Das Geschäft einer Nachrichtenseite sind Lastspitzen. Das ist die Methode, mit der wir eine darauf vorbereiten: die richtigen Logs lesen, wissen, wo die Obergrenze liegt, jede Ebene prüfen, bevor Geld ausgegeben wird, und rechnen.
In diesem Artikel 4 Abschnitte
- Verkehr legt Obergrenzen offen. Die Konfiguration setzt die Obergrenzen. Sich auf eine Lastspitze vorzubereiten heißt, sie zu finden, bevor das Publikum sie findet.
- Bestätigen Sie zuerst, welches Log den Verkehr der Seite tatsächlich trägt. Ein Standard-Log des Servers kann einen kleinen Anteil halten, während das vhost-Log der Seite selbst den Rest hält.
- Prüfen Sie jede Ebene, bevor Sie Geld ausgeben. Die Datenbank ist oft untätig und schnell, während sich die Arbeit eine Ebene darüber staut.
- Dann das Rechnen: Worker geteilt durch Sekunden pro Anfrage ist Ihre echte Obergrenze in Anfragen pro Sekunde. Dimensionieren Sie den Pool auf die Spitze, die Sie tatsächlich erreichen werden, plus Reserve.
Das Geschäft einer Nachrichtenseite sind Lastspitzen: Wenn die Meldung durchbricht, kommt das Publikum auf einmal. Sich darauf vorzubereiten ist selten eine Hardwarefrage. Es ist eine Konfigurationsfrage: die Anzahl der Worker, die Timeouts, die Logs, der Cache. So bereiten wir eine Seite darauf vor.
Lesen Sie zuerst das richtige Log
Die erste Disziplin ist richtiges Zählen. Auf einem typischen Webserver sind das Standard-Log und das vhost-Log der Seite selbst verschiedene Dateien, und das Standard-Log kann nur einen kleinen Anteil des Verkehrs halten. Dimensionieren Sie irgendetwas anhand des falschen Logs, und Sie dimensionieren es für die falsche Last.
Wissen Sie, wo die Obergrenze liegt
Unter Last sagen Ihnen die Anfragezeiten, wo das Limit liegt. Organische Langsamkeit streut: einige Anfragen etwas langsam, einige sehr langsam. Langsame Anfragen, die sich genau am Timeout des Gateways häufen, bedeuten, dass der Ebene hinter dem Gateway innerhalb ihres Budgets die Worker ausgehen. Das ist eine Sättigungssignatur, und sie zeigt direkt auf die Einstellung, die dimensioniert werden muss.
Prüfen Sie jede Ebene, bevor Sie Geld ausgeben
Bevor jemand RAM kauft oder die Datenebene aufrüstet, prüfen Sie sie. Eine Datenbank, die untätig und schnell ist, ohne langsame Abfragen, die alles in dem Moment beantwortet, in dem sie gefragt wird, ist nicht die Ebene, die dimensioniert werden muss. Die Ebene, die dimensioniert werden muss, ist die, deren Worker alle beschäftigt sind. Dieses Muster hat seinen eigenen Beitrag in kleiner dimensionieren, nicht größer.
Ihre Obergrenze ist Arithmetik
WORKERS
SEC / REQUEST
REQ / SEC
Die Vorbereitung ist Dimensionierung, kein Einkauf: der Worker-Pool berechnet aus der Spitze, die eine Nachrichtenseite tatsächlich erreichen wird, plus Reserve, innerhalb eines gemessenen Speicherbudgets pro Worker. Dann eine Cache-Ebene, die veraltete Inhalte ausliefert, wenn das Backend langsamer wird, damit ein ausgelastetes Backend zu leicht veralteten Seiten degradiert statt zu Fehlerseiten. Die Plattform fängt die Spitze ab.
“Der Verkehr findet die Obergrenze, die Sie setzen. Setzen Sie sie mit Absicht.”
Klare Antworten
Warum wirft eine Website unter starkem Verkehr 502-Fehler?+
Meist sind der Ebene hinter dem Gateway die Worker ausgegangen, und das Gateway gibt an seinem Timeout auf. Die Signatur sind langsame Anfragen, die genau bei einer Zahl festhängen. Zählen Sie die Fehler zuerst im richtigen vhost-Log, denn das Standard-Log hält womöglich nur einen Bruchteil Ihres Verkehrs.
Wie viele Worker sollte mein Anwendungsserver haben?+
Rechnen Sie es aus: Worker geteilt durch die durchschnittlichen Sekunden pro Anfrage ist Ihre Obergrenze in Anfragen pro Sekunde. Dimensionieren Sie auf die Spitze, die Sie tatsächlich erreichen werden, plus Reserve, innerhalb eines gemessenen Speicherbudgets pro Worker, statt dem Standardwert des Pakets zu vertrauen.
Ist die Datenbank der Engpass, wenn der Verkehr in die Höhe schnellt?+
Prüfen Sie es, bevor Sie Geld ausgeben. Sehen Sie nach, ob sie untätig oder beschäftigt ist und ob es langsame Abfragen gibt. Oft ist die Datenbank untätig und schnell, und die Arbeit staut sich eine Ebene darüber. Prüfen Sie zuerst jede Ebene.
Wie bereite ich eine Website auf eine Lastspitze vor?+
Rechnen Sie die Worker gegen Ihre realistische Spitze durch, bestätigen Sie, welche Logs Ihren Verkehr tatsächlich tragen, testen Sie unter Last bis zur berechneten Obergrenze, und schalten Sie Stale-on-Error-Caching davor, damit ein langsames Backend alte Seiten statt Fehler ausliefert.
Braucht mehr Verkehr nicht einfach mehr Server?+
Irgendwann ja, aber fast nie zuerst. Nutzen Sie zuerst die Kapazität, die Ihre Konfiguration zurückhält: richtig dimensionierte Pools, vernünftige Timeouts, Caching, das den Lesesturm abfängt. Hardware, die gekauft wird, um eine Konfigurationseinstellung abzudecken, ist die teuerste Konfigurationsänderung, die es gibt.
Erwarten Sie bald Ihren besten Tag?
Launch, Presse, Saisonspitze: Nennen Sie uns das Datum. Wir rechnen die Worker durch, lesen die richtigen Logs und machen aus der Spitze einfach ein weiteres Diagramm.
Mit einem Ingenieur sprechenSie haben das Ende erreicht.
Setzen Sie das Gelesene um
Was betreiben Sie?
Erzählen Sie uns von Workload, Traffic und Anforderungen an die Wiederherstellung. Beginnen Sie mit dem Server-Konfigurator oder besprechen Sie die Details mit einem Ingenieur.
Geschrieben von den Ingenieuren, die die beschriebene Infrastruktur bauen und betreiben.Mit einem Ingenieur sprechen