Wie die Nutzung unserer Online-Warteschlange einen Absturz der Website verhindert - wie viele gleichzeitige Nutzer kann ein Webserver bewältigen?

Warum sollte man ein virtuelles Wartezimmer auf Tarifbasis nutzen?

Ratenzahlung oder "One-out, one-in"? Wir wägen die Vor- und Nachteile ab.

Wir konnten keine Vorteile von "one-out, one-in" finden. Kurz gesagt besteht das Problem bei diesem Ansatz darin, dass der Webserver bei Besuchern von E-Commerce-Websites nicht weiß, wie viele gleichzeitige Benutzer er zu einem bestimmten Zeitpunkt hat. Das ist ein echter Showstopper. Hier ist der Grund.

Später in diesem Artikel erfahren Sie auch, wie Sie Ihre Website mit einem ratenbasierten virtuellen Raum schützen können.



Der am besten bewertete virtuelle Warteraum auf G2
G2 ist die meistbesuchte SaaS-Bewertungsseite der Welt

Was unsere Kunden über Queue-Fair sagen


Lasttest von http-Anfragen, wie viele Anfragen ein Webserver ohne zusätzliche Serverressourcen bewältigen kann

Wie viele gleichzeitige Benutzer kann ein Webserver bewältigen?

Wenn Sie wissen, wie viele gleichzeitige Benutzer ein Webserver verarbeitet, und die durchschnittliche Transaktionszeit oder Besuchsdauer von der ersten Seite in Ihrem Transaktionsfluss bis zur Bestellbestätigungsseite kennen, können Sie dies mit Hilfe des Little'schen Gesetzes in eine Warteschlangenrate umwandeln, indem Sie die Anzahl der Benutzer durch die Dauer teilen, etwa so:

Warteschlangenrate = Gleichzeitige Benutzer / Transaktionszeit

Wie genau ist ein ratenbasiertes Warteschlangensystem?

Queue-Fair liefert Ihnen die Besucher Ihrer Website in der von Ihnen festgelegten Geschwindigkeit - wir verfügen über die bei weitem genaueste Warteschlangen-KI der Branche, die sicherstellt, dass die von Ihnen gewünschte Anzahl von Besuchern pro Minute auch die Anzahl von Besuchern ist, die Sie pro Minute erhalten, wobei Personen, die nicht anwesend sind, wenn sie aufgerufen werden, sowie Personen, die zu spät zurückkommen, automatisch berücksichtigt werden.

Wie lässt sich dies auf die Anzahl der gleichzeitigen Benutzer übertragen? Natürlich wird nicht jeder Besucher, der auf Ihre Website gelangt, genau die durchschnittliche Transaktionszeit benötigen, um seine Transaktion abzuschließen, aber aufgrund des Gesetzes der großen Zahlen erhalten Sie mit Queue-Fair eine sehr konstante Anzahl von gleichzeitigen Nutzern.

Nehmen wir zum Beispiel an, Sie haben eine Warteschlangenrate von 100 Besuchern pro Minute. Wir werden jede Minute 100 Besucher in einem stetigen Strom auf Ihre Website schicken - das ist unser Job und wir sind erstaunlich gut darin. Nehmen wir weiter an, dass die Besucher Ihre Website im Durchschnitt (Mittelwert) fünf Minuten lang nutzen, wobei 70 % von ihnen zwischen 4 und 6 Minuten brauchen, von dem Moment, in dem sie die Warteschlange passieren, bis zu dem Moment, in dem sie ihre letzte Seitenanfrage stellen (unabhängig davon, ob sie eine Transaktion abschließen oder nicht). Das entspricht einer Standardabweichung von einer Minute beiderseits des Mittelwerts. Statistisch gesehen bedeutet das, dass auf jeden Besucher, der fünfeinhalb Minuten braucht, ein anderer kommt, der viereinhalb Minuten braucht. Diese Schwankungen in der individuellen Besuchsdauer über mehrere Sitzungen hinweg heben sich daher in der Regel gegenseitig auf, wenn man viele davon auf irgendeine Weise zählt. Das Gesetz der großen Zahlen besagt, dass diese Aufhebung immer genauer wird, je größer die Zahl der beteiligten Personen ist.

Betriebssystem maximale Anzahl von Webserver-Ressourcen
Berechnung der Durchschnittszahl für gleichzeitige Nutzer mit Konfidenzintervall

Wie genau? Das können wir mit ein wenig Statistik herausfinden. Es gibt eine Stichprobengröße von 5 * 100 = 500, das ist die große Zahl, um die es hier geht. Das ist die Anzahl der Personen, die du zählst. Das bedeutet, dass der Standardfehler im Mittelwert für die Transaktionszeit 1 ist (die Standardabweichung, 1 Minute), geteilt durch die Quadratwurzel des Stichprobenumfangs (also die Quadratwurzel aus 500) gemäß der statistischen Formel für den Standardfehler im Mittelwert, was einen Standardfehler im Mittelwert für die Transaktionszeit von 0,044 Minuten oder nur 2,7 Sekunden ergibt, was weniger als ein Prozent ist.

Das bedeutet, dass Sie bei einer Warteschlangenrate von 100 und einer Transaktionszeit von 5 Minuten (plus/minus eine Minute) für jeden einzelnen Besucher etwa 70 % der Zeit zwischen 495 und 505 gleichzeitige Benutzer auf Ihrer Website erwarten sollten.

Aber sind die Berechnungen auch korrekt? Es gibt hier einige Feinheiten - zum Beispiel ist die Stichprobengröße, die wir fröhlich quadrieren, nicht jedes Mal genau 500, wenn die gleichzeitigen Nutzer gezählt werden (d. h. zu jedem beliebigen Zeitpunkt), und auch eine normale (Gaußsche) Verteilung kann negative Transaktionszeiten ergeben, die im wirklichen Leben nicht vorkommen. Wir verwenden also einen Besucher-für-Besucher, Sekunde-für-Sekunde-Simulator, um Messungen vorzunehmen, um diese Art von Berechnungen zu überprüfen, und das sagt uns, dass Sie mit den oben genannten Zahlen in 70 % der Fälle zwischen 493 und 507 Besucher erwarten sollten, also hält die Mathematik bemerkenswert gut! Die Messung der Daten sagt uns auch, dass Ihre Website zu mindestens 95 % der Zeit 500 ± 15 gleichzeitige Benutzer haben wird.

Das ist wahrscheinlich stabiler als die Genauigkeit, mit der Ihr Webserver die Anzahl der Besucher auf Ihrer Website messen kann! Noch besser: Selbst wenn Sie keine Ahnung haben, wie lange die durchschnittliche Transaktionszeit oder die Standardabweichung für Ihre Besucher ist, gibt es diese mathematischen Größen, ob Sie sie nun kennen oder nicht, und Sie erhalten trotzdem eine stabile Last.

Das Ergebnis ist, dass Queue-Fair die von Ihnen gewünschte Anzahl von Besuchern pro Minute mit ziemlich perfekter Genauigkeit liefert, was zu einer sehr konstanten Anzahl von gleichzeitigen Benutzern auf Ihrer Website und einer stabilen Webserverlast führt, über die Sie die volle Kontrolle haben.

Hurra!


servers capacity can be exceeced with inaccurate queues Und nun eine Warnung. Es ist erwähnenswert, dass die Stabilität der Anzahl der gleichzeitigen Nutzer auf Ihrer Website - und damit die Stabilität Ihrer Serverlast - entscheidend davon abhängt, wie genau Ihr Virtual Waiting Room-Anbieter Ihnen die gewünschte Besucherzahl pro Minute übermittelt, und dies ist daher ein Schlüsselfaktor bei der Auswahl einer Virtual Waiting Room-Plattform. Da wir den genauesten Virtuellen Warteraum der Welt anbieten, stoppt niemand die Überflutung Ihrer Server besser als Queue-Fair.

Ein einfacher Weg zur Berechnung der Warteschlangenrate

Was ist, wenn Sie nicht wissen, wie viele gleichzeitige Benutzer ein Server bewältigen kann, oder wie lange die Transaktionszeit ist? Sie können sich die Seite ansehen, die wahrscheinlich der Engpass ist - in der Regel die Seite, die zum Anklicken einer Schaltfläche "Jetzt kaufen" führt. Verwenden Sie Google Analytics, um die monatlichen Besucher dieser Seite zu ermitteln, oder zählen Sie Ihre monatlichen Bestellungen. Teilen Sie dies durch 30 * 24 * 60 = 43.200, was der Anzahl der Minuten in einem Monat entspricht (ungefähr). Das sind Ihre durchschnittlichen Besucher pro Minute über den gesamten Monat. Multiplizieren Sie dies mit drei. Das sind Ihre durchschnittlichen Besucher pro Minute während der Geschäftszeiten (ungefähr). Verdoppeln Sie diesen Wert. Das ist wahrscheinlich ein sicherer Wert für die Warteschlangenrate.

Nehmen wir zum Beispiel an, Sie bearbeiten 100.000 Bestellungen pro Monat - das sind 100.000 Klicks auf die Schaltfläche "Jetzt kaufen". Das sind 100.000 / 43.200 = 2,31 Bestellungen pro Minute. Sie können davon ausgehen, dass die meisten dieser Bestellungen tagsüber erfolgen und Ihre Server nachts ruhiger sind. Multiplizieren Sie dies also mit 3 und Sie erhalten 7 Bestellungen pro Minute als grobe Schätzung dafür, wie ausgelastet Ihr Server während der Geschäftszeiten ist. Wenn das Ergebnis weniger als 50 beträgt: Es wird Spitzen- und Tiefpunkte in der Nachfrage geben. Wenn Ihr Server also in den Spitzenzeiten nicht merklich langsam ist, multiplizieren Sie diesen Wert mit 2 und Sie erhalten 14 aktive Nutzer pro Minute. Wenn die Zahl über 50 liegt, sind die Spitzen- und Tiefstwerte von Minute zu Minute geringer, und es ist nicht sicher, diese Zahl zu verdoppeln. Die Zahl, die Sie am Ende erhalten, ist wahrscheinlich eine sichere Zahl für die Warteschlangenrate, mit der Sie beginnen können, und entspricht der Anzahl der Anfragen pro Sekunde, die Sie sicher bewältigen können; Sie können sie jederzeit erhöhen, wenn Sie feststellen, dass Ihre Systeme bei dieser Rate immer noch für die Endbenutzerleistung ansprechbar sind.

Berechnung der maximalen Anzahl aktiver Benutzer für Ihre Webanwendung

Wenn Ihre Aufträge mit einem Zeitstempel versehen sind, können Sie auch die maximale Anzahl von Aufträgen betrachten, die Sie im letzten Monat in einer einzigen Minute erhalten haben. Seien Sie dabei jedoch vorsichtig, da Sie nicht wissen, wie viele Aufträge Sie in dieser Minute aufgrund der Verlangsamung Ihrer Server abgebrochen haben, also reduzieren Sie diesen Wert um 20%.

Im weiteren Verlauf dieses Artikels werden einige andere Möglichkeiten zur Berechnung der Warteschlangenrate erörtert.

Verwirrung über gleichzeitige Nutzer, gleichzeitige Verbindungen, gleichzeitige Sitzungen und durchschnittliche Sitzungsdauer

Habe dich #1: Gleichzeitige Benutzer vs. Gleichzeitige Anfragen vs. Gleichzeitige Verbindungen vs. Gleichzeitige Sitzungen

Es ist erwähnenswert, dass es im allgemeinen Sprachgebrauch mindestens zwei Definitionen von "Concurrent Users" gibt.

Wir verwenden die Definition "die Anzahl der Personen, die zu einem bestimmten Zeitpunkt an einem Transaktionsfluss beteiligt sind ". Das ist die wichtigste Zahl, die Sie wissen müssen, um die Warteschlangenrate festzulegen. Das ist die Anzahl der Nutzer, die Ihre Website in diesem Moment besuchen. Die Anzahl der gleichzeitigen Sitzungen ist in der Regel etwas größer als die Anzahl der gleichzeitigen Verbindungen oder Benutzer, da einige der Sitzungen gerade auslaufen, was die durchschnittliche Sitzungsdauer erhöht.

Im Gegensatz dazu steht die Anzahl der gleichzeitigen Anfragen, d. h. die Anzahl der HTTP-Anfragen, die von Ihrem Webserver zu einem bestimmten Zeitpunkt verarbeitet werden. Sehr verwirrend ist, dass viele Techniker "wie viele gleichzeitige Anfragen" meinen, wenn sie von "wie vielen gleichzeitigen Benutzern" sprechen.

Dann gibt es noch "Concurrent Connections" (oder gleichzeitige TCP-Verbindungen zum selben Server-Port auf Ihrer Netzwerkkarte), das ist die Anzahl der TCP/IP-Sockets, die gleichzeitig an Ihrem Server-Port oder Backend-Dienst geöffnet sind. Bei Seitenanfragen lassen Browser die Verbindung standardmäßig offen, falls weitere Anfragen von der Seite gestellt werden oder der Benutzer zu einer anderen Seite wechselt. Dadurch wird die Anzahl der Anfragen pro Sekunde zum Öffnen neuer TCP/IP-Verbindungen reduziert, was den Serverprozess effizienter macht. Die Zeitüberschreitungen für diese gleichzeitigen Verbindungen variieren je nach Browser, von 60 Sekunden bis zu "never-close". Möglicherweise schließt Ihr Server die Verbindungen auch automatisch nach einer gewissen Zeit der Inaktivität. Auf Linux-Webservern können Sie mit diesem Befehl die Anzahl der gleichzeitigen Verbindungen zum selben Server-Port ermitteln:

netstat -aenp | grep ":80 \|:443 " | wc -l

die Sie ausprobieren können, wenn Sie neugierig sind. Manche Leute nennen dies auch "Concurrent Users", obwohl es eigentlich "Concurrent Connections" heißt.

Wenn Sie Ihren Hosting-Provider bitten, Ihnen die maximale Anzahl der gleichzeitigen Benutzer zu nennen, die Ihr Webserver verarbeiten kann (wie viel Spitzenverkehr), wird er Ihnen wahrscheinlich eine Zahl für gleichzeitige Sitzungen, gleichzeitige Anfragen oder gleichzeitige Verbindungen nennen, und zwar aus dem einfachen Grund, dass er Ihre durchschnittliche Transaktionszeit, die Anzahl der Seiten in Ihrem Transaktionsfluss oder eine der anderen Informationen nicht kennt, die es ihm ermöglichen würden, Ihnen zu sagen, wie viele gleichzeitige Benutzer Ihr Webserver verarbeiten kann. Alle diese Zahlen haben unterschiedliche Werte.

Wenn Sie Ihren Hosting-Provider oder Ihr technisches Team nach Informationen über den maximalen Datenverkehr fragen, sollten Sie unbedingt klären, ob damit gleichzeitige Benutzer, gleichzeitige Sitzungen, gleichzeitige Anfragen oder gleichzeitige Verbindungen gemeint sind.

Wenn Sie dies falsch machen, kann Ihre Website abstürzen!

Der Grund dafür ist folgender. Jede Seite ist eine einzelne HTTP-Anfrage, aber alle Bilder, Skripte und anderen Dateien, die aus Ihrer Webanwendung stammen und die der Browser zur Anzeige der Seite verwendet, sind auch HTTP-Anfragen.

Nehmen wir an, Ihr technisches Team hat Ihnen gesagt, dass der Server 500 gleichzeitige Benutzer unterstützt, aber sie meinen eigentlich 500 gleichzeitige Anfragen. Mit Ihrer 5-minütigen Transaktionszeit verwenden Sie die obige Formel und gehen davon aus, dass Ihre Website 100 Besucher pro Minute unterstützen kann.

Geht das? Nein.

Während die Nutzer den Transaktionsfluss durchlaufen, stellen sie eigentlich nur Anfragen an Ihre Server, während die einzelnen Seiten geladen werden. Dies wirkt sich darauf aus, wie viel Verkehr pro Sekunde oder aktive Benutzer Ihr Server bewältigen kann. Von der fünfminütigen Transaktionszeit entfallen nur wenige Sekunden auf einen durchschnittlichen Benutzer. Sie könnten also denken, dass 500 gleichzeitige Anfragen bedeuten, dass Sie viel mehr gleichzeitige Benutzer bewältigen können, aber da könnten Sie sich täuschen. Verstehen Sie jetzt, warum es so kompliziert ist, die Kapazität Ihrer Website in Bezug auf den Datenverkehr oder die Gesamtzahl der aktiven Nutzer zu ermitteln?

achten Sie zuerst auf Ihre Server-Ressourcen, wenn Sie berechnen, wie viele Anfragen Ihre Webseiten erhalten dürfen, um jedem einzelnen Nutzer ein gutes Erlebnis zu bieten

Konvertierung gleichzeitiger Anfragen in gleichzeitige Benutzer

Um die maximale Anzahl der gleichzeitigen Benutzer aus der maximalen Gesamtzahl der gleichzeitigen Anfragen zu berechnen, müssen Sie auch Folgendes wissen

  1. Die Anzahl der Seiten in Ihrem Transaktionsablauf
  2. Die durchschnittliche Transaktionszeit der Besucher von der ersten bis zur letzten Seite in Ihrem Fluss
  3. Wie viele Abrufe eine Seite im Durchschnitt hat
  4. Die durchschnittliche Zeit, die Ihr Server für die Bearbeitung einer einzelnen HTTP-Anfrage benötigt

1) und 2) kennen Sie wahrscheinlich schon - in unserem Beispiel sind es 6 Seiten und 5 Minuten. Sie können die Seiten, die Sie während einer Transaktion sehen, leicht zählen. Wenn Sie die durchschnittliche Transaktionszeit nicht kennen, kann Google Analytics sie Ihnen sagen, oder Sie können die Protokolle Ihres Webservers überprüfen.

Für 3) und 4) kann der Firefox-Browser helfen. Klicken Sie mit der rechten Maustaste auf eine Seite Ihrer Website, wählen Sie Element inspizieren und die Registerkarte Netzwerk. Drücken Sie dann CTRL-SHIFT-R, um die Seite vollständig zu aktualisieren. In der Liste sehen Sie die Netzwerkladezeiten für jedes Element der Seite. Vergewissern Sie sich, dass Sie die Übertragungsgrößen in der Spalte Übertragen sehen können, da andernfalls Dateien aus einem Zwischenspeicher bereitgestellt werden könnten, was Ihre Berechnungen durcheinander bringen könnte. Es kann sein, dass einige Skripte und andere Ressourcen von anderen Servern als Ihrer Website stammen, daher können Sie den Domainnamen Ihrer Website in das Filterfeld auf der linken Seite eingeben. Um die Spalte Dauer anzuzeigen, klicken Sie mit der rechten Maustaste auf eine beliebige Spaltenüberschrift und wählen Sie aus dem Popup-Menü die Option Timings -> Dauer. Ihr Bildschirm sollte wie folgt aussehen:

google verarbeitet ein richtig konfiguriertes nginx mit google analytics für den Bilderupload

Die Firefox-Netzwerk-Registerkarte für diese Seite, die Dauer und Anzahl der Anfragen von queue-fair.com anzeigt

Die Dateien, die für die Darstellung Ihrer Seiten verwendet werden, können von verschiedenen Websites stammen. Daher sollten Sie den Filter oben links auch dazu verwenden, nur die Dateien Ihrer Website anzuzeigen - aber nur, wenn Sie sicher sind , dass diese Dateien von anderen Websites nicht der Grund für langsame Seitenladevorgänge oder ein Teil des Engpasses sind.

Firefox zählt die Anfragen für Sie unten links in der Anzeige und zeigt 36 HTTP-Anfragen für nur diese eine Seite. an.

Sie müssen dies für jede Seite in Ihrem Transaktionsfluss tun - zählen Sie die Gesamtzahl und teilen Sie sie durch die Anzahl der Seiten, um die durchschnittliche Anzahl der HTTP-Anfragen für jede Seite (Nummer 3) in unserer Liste zu ermitteln. Sie sehen jetzt, warum die Anzahl der untergeordneten Anfragen für jede HTML-Seite ein so wichtiger Faktor dafür ist, wie viel Verkehr Ihr Webserver bewältigen kann.

Für Nummer 4) müssen Sie sich die Spalte Dauer ansehen und den Durchschnitt aller HTTP-Anfragen für alle Ihre Seiten ermitteln. Wenn Sie sich nicht sicher sind, gehen Sie von einer halben Sekunde aus - hier gibt es ohnehin eine Menge Unsicherheiten (siehe unten).

Berechnung der Anzahl der gleichzeitigen Sitzungen, der Anzahl der Benutzer und der Anzahl der Anfragen pro Sekunde an Ihre Webanwendung, sei es ein einzelner Server oder ein statischer Inhalt

Rechnen Sie nach

Lassen Sie uns einige Beispielzahlen nennen. Wir haben bereits gesagt, dass es im Prozessablauf des Beispielservers sechs dynamische Seiten gibt (1) und dass die durchschnittliche Transaktionszeit fünf Minuten beträgt (2). Nehmen wir für 3) 36 HTTP-Anfragen pro Seite an, und für jede HTTP-Anfrage eine halbe Sekunde für die Serververarbeitungszeit, also 4).

Mit diesen Zahlen kann ein Server, der 500 gleichzeitige Anfragen bewältigen kann, 500 / (0,5 Sekunden) = 1000 HTTP-Anfragen pro Sekunde bewältigen, was 60.000 HTTP-Anfragen pro Minute entspricht, wenn er vollständig ausgelastet ist.

Während der fünfminütigen Transaktionszeit kann es 5 * 60.000 = 300.000 HTTP-Anfragen verarbeiten. Das scheint viel zu sein, oder?

Aber für jeden Besucher gibt es sechs Seiten mit durchschnittlich je 36 HTTP-Anfragen, also 6 * 36 = 216 Anfragen

Die Kapazität von 300.000 HTTP-Anfragen kann also theoretisch 300.000 / 216 = 1.389 gleichzeitige Benutzer verarbeiten

Habe dich #2: Webserver werden bei Belastung langsamer

Hey, das ist großartig! Wir dachten, wir könnten nur eine Warteschlangenrate von 100 haben, aber 1.389 / 5 Minuten = 278 Besucher pro Minute, also können wir eine höhere Warteschlangenrate haben!

Nun, wahrscheinlich nicht. Zum einen werden Ihre Besucher nicht in Abständen von genau einer halben Sekunde Anfragen senden, wie es die obige Berechnung voraussetzt. Noch wichtiger ist, dass Sie Ihre Eingabedaten gemessen haben, als die Website nicht ausgelastet war. Müll rein, Müll raus.

Wenn die Website ausgelastet ist, braucht der Server länger, um Anfragen zu bearbeiten - Sie werden das auf anderen Websites bemerkt haben, wenn viel los ist, dass Sie länger auf Seiten warten. Dadurch erhöht sich die durchschnittliche Zeit, die Ihr Server für die Bearbeitung einer einzelnen HTTP-Anfrage benötigt (4), was den maximalen Durchsatz verringert. Nehmen Sie also die 278 Besucher pro Minute und halbieren Sie sie. Dann halbieren Sie sie noch einmal. Bei maximaler Auslastung können Sie realistischerweise mit etwa 70 neuen Besuchern pro Minute rechnen.

je höher die Belastung durch den Datenverkehr ist, desto langsamer werden die Maschinen

Zu den weiteren Störfaktoren gehört die Zwischenspeicherung (Caching), d. h. die Browser Ihrer Besucher müssen nicht für jede einzelne Seite jede einzelne Anfrage stellen - dies bedeutet in der Regel, dass der Server weniger Ressourcen benötigt, und kann die Anzahl der neuen Besucher pro Minute erhöhen, die Ihr Server verarbeiten kann. Load Balancer, die die Last auf mehrere Server verteilen, und die Bereitstellung statischer Inhalte anstelle dynamischer Seiten können den Serverprozess ebenfalls beschleunigen, da jeder Server weniger Ressourcen benötigt.

Sie werden auch feststellen, dass nicht alle Seiten gleich viel Zeit in Anspruch nehmen, da einige weniger Ressourcen für die Erstellung und Bereitstellung benötigen als andere. Datenbanksuchen, Suchabfragen und Aktualisierungen dauern am längsten, so dass Sie irgendwo in Ihrem Prozess einen Engpass haben, wo sich die Leute stauen und darauf warten, dass Kreditkartendaten verarbeitet und Bestellungen gespeichert werden, oder darauf warten, dass die Verfügbarkeit geprüft wird. Jeder Transaktionsfluss hat einen langsamsten Schritt, so dass es immer irgendwo einen Engpass gibt, und es gibt immer einen Maximalwert als Antwort auf die Frage, wie viele gleichzeitige Benutzer ein Webserver bewältigen kann - und dabei kann es mehrere Grenzen geben. In diesem Fall sollten Sie die Warteschlangenrate niedrig genug ansetzen, um sicherzustellen, dass Ihr Server über genügend Rechenzeit verfügt, um genügend Leute gleichzeitig für den langsamsten Schritt in Ihrem Prozess zu verarbeiten, damit sich die Leute dort nicht stapeln. Andernfalls kann Ihr Webserver buchstäblich zum Stillstand kommen.

unsicher, wie man die Serverkapazität für jeden einzelnen Benutzer abschätzen kann

Was soll ich also tun?

Wir haben die Erfahrung gemacht, dass beim ersten Verkauf jeder die Fähigkeit seiner Server überschätzt, ein hohes Verkehrsaufkommen zu bewältigen.

Alle.

Die genaue Bestimmung der durchschnittlichen Sitzungsdauer und der Endbenutzerleistung bei langsamem oder hohem Datenverkehr ist nichts für schwache Nerven. Am besten führen Sie einen richtigen Lasttest durch, bei dem "falsche" Kunden den Bestellvorgang durchlaufen, während Sie den Lasttest genau so durchführen, wie sie es im wirklichen Leben tun würden. Sie stellen die gleichen HTTP-Anfragen in der gleichen Reihenfolge, mit den gleichen Wartezeiten zwischen den Seiten beim Lasttest, wie Sie sie im wirklichen Leben sehen, und behalten Ihre Prozessorlast, den IO-Durchsatz und die Antwortzeiten im Auge, während Sie die Anzahl der virtuellen Besucher erhöhen. Sie können dafür Apache JMeter verwenden (wir verwenden auch K6 für geringere Lasten oder langsamere Rechner), aber egal welches Tool Sie verwenden, es ist zeitaufwändig und schwierig, das Verhalten jedes einzelnen Benutzers genau richtig zu imitieren (insbesondere wegen der Komplexität des Caching). Selbst dann nehmen Sie Ihre maximale Zahl und halbieren Sie sie.

In Ermangelung dessen sollte man mit Vorsicht vorgehen.

Sie können die Warteschlangenrate für jede Queue-Fair-Warteschlange jederzeit problemlos über das Queue-Fair-Portal ändern. Beginnen Sie mit 10 Besuchern pro Minute oder Ihrer Transaktionsrate an einem normalen Tag, sehen Sie sich an, wie das eine Weile läuft, nachdem Ihre Tickets in den Verkauf gegangen sind, und wenn alles gut aussieht, Ihre Prozessorlast gering ist, Ihre SQL-Datenbank in Ordnung ist und (vor allem) Ihre Seiten ansprechend sind, wenn Sie STRG-SHIFT-R drücken, verdoppeln Sie die Rate, warten Sie ein wenig und wiederholen Sie den Vorgang. Sie werden bald die tatsächliche Rate finden, die Sie während dieses "Lastausgleichs" benötigen (sehen Sie, was wir da gemacht haben?), und denken Sie daran, dass es aus Sicht der Kundenerfahrung in Ordnung ist, die Warteschlangenrate zu erhöhen, da dies dazu führt, dass die geschätzten Wartezeiten, die Ihre Kunden in der Warteschlange sehen, sinken, und jeder ist froh, eine Antwortzeit zu sehen, die eine kürzere geschätzte Wartezeit liefert.

Was Sie vermeiden wollen, ist, die Warteschlangenrate zu hoch einzustellen und dann in die Lage zu kommen, sie absenken zu müssen, da dies a) bedeutet, dass die Leute, die die Site benutzen, langsame Seitenladungen erleben, und b) die geschätzten Wartezeiten erhöhen lässt. Alle Leute in Ihrer Warteschlange werden seufzen!

Habe dich #3: Zu schnelles Erhöhen der Rate nach dem Öffnen einer Warteschlange

Denken Sie daran, dass es irgendwo in Ihrem Bestellprozess einen Engpass geben wird - jede Transaktion hat einen langsamsten Schritt - und dass sich dort mehrere Sitzungen anhäufen werden. Was Sie nicht wollen, ist, dass Sie nach einer Minute des Ticketverkaufs feststellen, dass die Prozessorlast Ihres Servers weit unter der maximalen Zahl liegt, und die Rate erhöhen. Ihre Besucher sind wahrscheinlich noch nicht einmal bis zur Schaltfläche "Jetzt kaufen" gekommen. Sie sollten abwarten, bis Ihre SQL-Datenbank neue Bestellungen mit der gleichen oder einer ähnlichen Rate wie Ihre Warteschlangenrate meldet, und dann Ihre Messungen und Reaktionsfähigkeitstests durchführen. Denken Sie daran, dass es jedes Mal, wenn Sie die Rate erhöhen, genauso lange dauert, bis die zusätzlichen Besucher Ihren Engpass erreichen, so dass Sie die Leistung Ihres Servers bei der neuen Rate erst nach Ablauf dieser Zeit genau beurteilen können.

die Entscheidung über den Verbrauch von Server-Ressourcen zu verlangsamen
Server schnappen ein, wenn die Serverkapazität überschritten wird

Habe dich #4: Schnappen Sie Ihre Server

Wir haben bereits besprochen, dass es am besten ist, die Warteschlangenrate schrittweise zu erhöhen, sobald Ihre Warteschlange geöffnet ist. Sie wissen wahrscheinlich, dass Ihre Server eine Grenze haben, die nicht überschritten werden kann, ohne dass das System abstürzt, und vielleicht wissen Sie sogar, wie hoch diese Grenze ist. Was Sie aber vielleicht nicht wissen, ist, dass es in der Regel kaum Anzeichen dafür gibt, dass sich die Last dieser Grenze nähert - oft nur ein paar Fehler oder Warnungen oder eine Prozessorlast von über 80 %.

Wenn Webdienste ausfallen, neigen sie dazu, sehr schnell zu "knicken" oder zu versagen. Das liegt normalerweise daran, dass sich interne Warteschlangen bilden, sobald Ihr System die Anfragen nicht mehr so schnell verarbeiten kann, wie sie eingehen. Ihr System muss dann nicht nur die Anfragen, sondern auch die internen Warteschlangen verarbeiten, verwalten und speichern, und das ist es, was die Server in die Knie zwingt. Und zwar sehr schnell. Wenn das passiert, können Ihre Server vielleicht eine Zeit lang mit einer Fehlerseite reagieren, aber das hilft Ihnen nicht, weil die Besucher, die sie sehen, sofort auf Aktualisieren klicken, was die Belastung noch erhöht.

Überfordern Sie Ihre Server also nicht mehr als nötig. Das Risiko, die letzten 20 % der CPU-Zeit auszunutzen, lohnt sich normalerweise nicht. Wenn die Größe der Warteschlange, die im Queue-Fair-Portal angezeigt wird (die gelbe Warteschlange und die Linie in den Diagrammen), von Minute zu Minute abnimmt oder auch nur langsamer ansteigt und die angezeigte Wartezeit 50 Minuten oder weniger beträgt, dann verarbeiten Sie die Aufträge schnell genug, und die Warteschlange wird sich schließlich leeren und keine Warteschlangenseiten mehr anzeigen, ohne dass Sie etwas tun müssen und ohne dass Sie Ihrem Chef sagen müssen, dass Sie sie zu sehr beansprucht und kaputt gemacht haben. Sie werden das Ziel irgendwann erreichen, solange die Geschwindigkeit des Vorderteils der Warteschlange höher ist als die Anzahl der Beitritte pro Minute (die beide im Queue-Fair-Portal angezeigt werden) - der Wendepunkt ist normalerweise mindestens ein paar Minuten nach jedem Ereignis erreicht. Wenn Sie ein Produkt mit begrenzter Stückzahl verkaufen, werden Sie wahrscheinlich ausverkauft sein, bevor der Wendepunkt erreicht ist.

Wenn Sie die Warteschlangenrate versehentlich zu hoch angesetzt haben und Ihre Server ausfallen, kann Queue-Fair Ihnen helfen, den Betrieb schnell wieder aufzunehmen - stellen Sie die Warteschlange einfach auf "Halten", bis Ihre Server wieder bereit sind, Besucher zu verarbeiten. Im Warteschleifenmodus sehen die Besucher in der Warteschleife eine spezielle Warteschleifenseite, die Sie vor Ihrem Online-Event gestalten können. Wenn die Warteschlange auf "Halten" gestellt ist, wird niemand von vorne durchgelassen, aber neue Internet-Besucher können sich immer noch hinten anstellen, um fair in die Warteschlange aufgenommen zu werden, sobald die Blockade beseitigt ist, was sehr schnell geschehen wird, da Queue-Fair Ihre Website vor der Nachfrage schützt. Die Seite "Halten" ist eine bessere Benutzererfahrung als die Einstellung einer sehr niedrigen Warteschlangenrate, besonders wenn Sie sie aktualisieren, um den Besuchern mitzuteilen, wann Sie erwarten, dass die Warteschlange wieder geöffnet wird, was mit dem Portal-Seiteneditor leicht zu bewerkstelligen ist, selbst wenn sich bereits Hunderttausende von Besuchern in der Warteschlange befinden - und im "Halten"-Modus können Sie sie sogar einen nach dem anderen mit Queue-Fairs einzigartigem "Einen zulassen"-Button durchlassen, wenn Sie das müssen, während sich Ihr System von seinem Einbruch erholt.

Wenn Sie also feststellen, dass Ihre Server während Ihrer Veranstaltung eine Pause brauchen, ist die Seite "Halten" genau das Richtige für Sie, und sie hilft Ihren Servern außerdem, sich schneller zu erholen.

Schlussfolgerung

In diesem Artikel haben wir erklärt, warum eine ratenbasierte Warteschlange immer der richtige Weg ist, und zwei Methoden zur Berechnung der benötigten Rate vorgestellt. Solange Sie jedoch keine vollständigen und genauen Lasttests mit virtuellen Besuchern für Ihren gesamten Transaktionsfluss durchgeführt haben und sich dessen wirklich super extra mega sicher sind, ist unser Rat immer derselbe:

  1. Beginnen Sie mit einer Warteschlangenrate von 10, oder Ihrer Transaktionsrate an einem normalen Tag.
  2. Beobachten Sie Ihre Prozessorlast und andere Leistungsindikatoren.
  3. Warten Sie, bis neue Aufträge in Ihrer SQL-Datenbank mit der gleichen oder einer ähnlichen Rate wie Ihre Warteschlangenrate erfasst werden.
  4. Drücken Sie CTRL-SHIFT-R auf Ihren Seiten, um die Reaktionsfähigkeit zu prüfen.
  5. Erhöhen Sie die Warteschlangenrate um nicht mehr als 20 %.
  6. Gehen Sie zurück zu Schritt 2 und warten Sie erneut.
  7. Sobald die Größe der Warteschlange abnimmt oder stetig und weniger schnell pro Minute ansteigt und die angezeigte Wartezeit weniger als 50 Minuten beträgt, braucht sie nicht mehr schneller zu werden.
  8. Lehnen Sie sich zurück und entspannen Sie sich! Queue-Fair hat alles für Sie.

Wenn Sie ein Produkt in begrenzter Menge verkaufen, brauchen Sie auch Schritt 7 nicht zu beachten.

Das gilt für Ihre erste Warteschlange, wenn Sie die tatsächliche maximale Warteschlangenrate, die Ihr System unterstützen kann, noch nicht kennen. Für nachfolgende Warteschlangen können Sie, sobald Sie die Warteschlangenrate gemessen haben, die Ihr System tatsächlich bewältigen kann, möglicherweise wieder dieselbe Zahl verwenden - aber nur, wenn sich an Ihrem System nichts geändert hat. In der Praxis wird Ihr System wahrscheinlich ständig weiterentwickelt und modifiziert, und Sie wissen vielleicht nicht, wie sich die jüngsten Änderungen auf Ihre maximale Warteschlangenrate ausgewirkt haben - warum beginnen Sie also nicht mit der Hälfte Ihres zuvor gemessenen Wertes und wiederholen den obigen Prozess?

Denken Sie daran: Vorsicht ist besser als Nachsicht.


Hunderte von führenden Organisationen vertrauen
unseren Warteschlangenlösungen

Customer 1 Customer 2 Customer 3 Customer 4 Customer 5 Customer 6

Die einfache Lösung für Ihren Internet-Verkehrsanstieg

Los geht's