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.
Traditionell werden E-Commerce-Server so eingerichtet, dass sie eine maximale Anzahl gleichzeitiger Benutzer unterstützen, und die Last wird oft auf diese Weise definiert. Es gibt ein Problem bei der Verwendung dieses Ansatzes für den Betrieb einer Warteschlange für eine Website - ein Problem, das wir mit Raten lösen.
Das Problem besteht darin, dass die Besucher den Webserver nur dann tatsächlich nutzen, wenn ihr Browser die einzelnen Webseiten lädt.
Nehmen wir zum Beispiel an, eine E-Commerce-Website verkauft Eintrittskarten. Vom Beginn der Besucherreise bis zum Ende der Besucherreise (der Benutzersitzung) gibt es sechs Seiten, da der Besucher
Der gesamte Transaktionsprozess dauert im Durchschnitt fünf Minuten.
Nehmen wir an, dass jede Minute 100 Besucher eintreffen, um Tickets zu kaufen, und die durchschnittliche Zeit für den Abschluss des Vorgangs fünf Minuten beträgt. Zu einem bestimmten Zeitpunkt befinden sich 500 Personen gleichzeitig im Transaktionsprozess, und der Server muss für die Unterstützung von 500 gleichzeitigen Benutzern ausgelegt sein.
Man könnte meinen, dass man einen Zähler für gleichzeitige Benutzer erstellen könnte, der jedes Mal erhöht wird, wenn ein neuer Besucher auf der Homepage ankommt, und der jedes Mal erniedrigt wird, wenn ein Besucher die Transaktion abschließt, und dass dies Ihnen sagen würde, wie viele Benutzer ein einzelner Server zu einem bestimmten Zeitpunkt bearbeitet, aber das funktioniert nicht.
Es wird nicht funktionieren, weil nicht jeder Besucher die Transaktion abschließt. Die Leute ändern ihre Meinung, lassen sich ablenken oder gehen weg und kommen später wieder. Da der Webserver nur dann mit den Besuchern interagiert, wenn ihre Browser Seiten laden, kann er nicht wissen, wann oder bei wem dies geschehen ist.
Um festzustellen, dass ein Besucher nicht mehr am Transaktionsprozess beteiligt ist, muss der einzelne Server abwarten, bis keine Seitenanfragen mehr von diesem Besucher eingehen, und dann die Sitzung dieses Besuchers beenden. Die Timeouts müssen immer viel länger sein als die durchschnittliche Transaktionszeit (in diesem Beispiel z. B. 20 Minuten), da einige Besucher viel länger brauchen als andere, um ihre Transaktion abzuschließen.
Man könnte die Möglichkeit hinzufügen, auch den fiktiven Zähler für gleichzeitige Benutzer jedes Mal zu verringern, wenn eine Besuchersitzung auf diese Weise beendet wird, aber das führt zu sehr schlechten Ergebnissen.
Wenn 10 % der 100 Besucher, die jede Minute eintreffen, ihre Transaktion nicht abschließen, sind die Besucher, die ihre Transaktion abschließen, im Durchschnitt fünf Minuten lang aktiv, und die Besucher, die ihre Transaktion nicht abschließen, gelten immer mindestens 20 Minuten lang als aktiv (eigentlich ist die Sitzungszeit plus die durchschnittliche Sitzungsdauer wahrscheinlicher, wenn mehrere Sitzungen berücksichtigt werden).
Das sind 90 * 5 + 10 * 20 = 650, und der Server meldet 650 gleichzeitige Benutzer, obwohl er eigentlich weniger beschäftigt ist!
Darüber hinaus nutzen bis zu 10 * 20 = 200 dieser gleichzeitigen Nutzer die Website nicht und sind dabei, den Vorgang abzubrechen, was über 30 % der gemeldeten gleichzeitigen Nutzer ausmacht, obwohl nur 10 % der Besucher die Transaktion nicht abschließen.
Nehmen wir nun an, man möchte dieser Website eine Warteschlange hinzufügen, die von unserem Zähler für gleichzeitige Benutzer kontrolliert wird. Sobald die Website ausgelastet ist, wird eine Person, die sich an der Spitze der Warteschlange befindet, erst auf die Website weitergeleitet, wenn der Zähler zurückgeht. Dies wird als "One-out-one-in"-Warteschlange bezeichnet. In 30 % der Fälle wartet eine Person am Anfang der Warteschlange darauf, dass jemand, der seine Transaktion nicht abschließen will, seine Transaktion nicht abschließt.
Hinzu kommt der zusätzliche technische Integrationsaufwand und die Belastung der Website durch die Erstellung und Ausführung des Zählers und die gemeinsame Nutzung dieser Informationen mit dem Warteschlangensystem. Wenn der Mechanismus zur gemeinsamen Nutzung oder Zählung ausfällt oder nicht funktioniert, bleibt die Warteschlange stecken. Noch schlimmer ist es, wenn der Einzelserver so ausgelastet ist, dass er den Warteschlangenserver nicht aktualisieren kann, um dem Warteschlangenserver mitzuteilen, dass er die nächste Person hereinlassen soll.
All diese Probleme lassen sich leicht und einfach lösen, indem man die Besucher mit einer konstanten, festen Rate - in diesem Fall 100 Besucher pro Minute - an den Anfang der Warteschlange stellt.
Auf diese Weise muss die tatsächliche Anzahl der gleichzeitigen Nutzer nicht gemessen werden, und es ist keine komplexe Integration mit der Ticket-Website erforderlich, und es besteht kein Risiko, dass die Warteschlange stecken bleibt.
Deshalb haben wir 2004 das ratenbasierte virtuelle Wartezimmer für stark frequentierte Websites erfunden und patentiert.
Erstaunliches und einfaches Produkt! Queue-Fair ist wirklich schön. Es ist so einfach, die Parameter in Echtzeit einzustellen, und es ist auch so einfach zu integrieren. Der Support ist reaktiv und freundlich. Ich habe ein virtuelles Wartezimmer in 15 Minuten eingerichtet, einschließlich der Einstellungen! So schütze ich meine Infrastruktur mit Queue-Fair vor all diesen Verkehrsspitzen.
Ihre Software hat dafür gesorgt, dass alle in einer Warteschlange fernab unseres Servers standen und einen sanften Fluss von Käufern durch das System ermöglichten. Das war großartig! Jeder Online-Shop, der einen großen Kundenansturm zu bewältigen hat, würde dies sehr nützlich finden. Vielen Dank und machen Sie weiter so!
Glänzend! Wir sind sehr glücklich und zufrieden mit Queue-Fair, es ist wunderbar, dieses Maß an Unterstützung zu haben. Der Dienst funktioniert perfekt - wir haben Tausende von Tickets in kurzer Zeit verkauft, und Queue-Fair hat uns geholfen, den Datenverkehr in Spitzenzeiten zu bewältigen! Wir empfehlen Queue-Fair auch an unsere Servicepartner weiter. Ich bin wirklich zufrieden!
Die Mitarbeiter von Queue-Fair haben uns bei der Implementierung ihres Warteschlangensystems innerhalb eines Tages mehr als nur geholfen. Mit über 25.000 Personen in der Warteschlange halfen sie uns, den Verkehr während unserer Spitzenzeiten zu bewältigen. Queue-Fair tut das, wofür es gedacht ist: Menschen in eine Warteschlange stellen, und das zu einem wettbewerbsfähigen Preis. Wir sind mit dem Queue-Fair-System sehr zufrieden und werden es auch bei zukünftigen Veranstaltungen einsetzen.
Queue-Fair war genau das, was wir für die Verwaltung des Datenverkehrs brauchten, und der Support-Service ist großartig! Das System hat sehr gut funktioniert ! Wir haben uns nach mehreren Unternehmen umgesehen und haben ohne Zweifel das beste gefunden ! Vielen Dank, Queue-Fair!
Vielen Dank, dass Sie unsere Anfrage so schnell bearbeitet haben. Wir haben am Mittwoch um 21 Uhr eine E-Mail geschickt und am Donnerstag um 11 Uhr eine vollständig gebrandete Warteschlangenseite erhalten, die sofort einsatzbereit war. Einfach genial! Das Dashboard und die Funktionen sind großartig - wirklich intuitiv, wirklich sauber und einfach zu bedienen. Wir haben für unsere Produkteinführungsveranstaltung über 22.000 Personen in die Warteschlange gestellt, und das zu äußerst wettbewerbsfähigen Kosten. Vielen Dank für alles! Ich freue mich wirklich, Queue-Fair ein glänzendes Zeugnis ausstellen zu können und würde das Unternehmen jedem empfehlen, der ein Warteschlangensystem für seine Veranstaltung oder Promotion benötigt.
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
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.
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!
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.
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.
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.
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.
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?
Um die maximale Anzahl der gleichzeitigen Benutzer aus der maximalen Gesamtzahl der gleichzeitigen Anfragen zu berechnen, müssen Sie auch Folgendes wissen
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:
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).
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
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.
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.
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 wie im echten Leben durchführen. Sie stellen die gleichen HTTP-Anfragen in der gleichen Reihenfolge, mit den gleichen Wartezeiten zwischen den Seiten, wie Sie sie im echten Leben sehen, und behalten Ihre Prozessorlast, den IO-Durchsatz und die Antwortzeiten im Auge, während Sie die Zahl 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 sollten Sie Ihre Maximalzahl nehmen und halbieren.
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, erhöhen Sie die Rate um nicht mehr als 20 Prozent, warten Sie ein wenig und wiederholen Sie das. 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, sich verringern, 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!
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.
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.
Wenn es länger als eine Sekunde dauert, bis die Besucher Ihre Seiten sehen, drücken sie auf Aktualisieren. Wenn ein Besucher auf Aktualisieren drückt, weiß Ihr Webserver nicht, dass der Besucher nicht mehr auf die Antwort auf die ursprüngliche Anfrage wartet. Wenn sowohl die ursprüngliche als auch die Aktualisierungsanforderung empfangen werden, verarbeitet Ihr Webserver beide. Das bedeutet mehr Arbeit für Ihren Webserver, noch langsamere Antworten für alle Ihre Besucher und noch mehr Besucher, die auf Refresh klicken, was zu einem Teufelskreis führt, der Ihren Webserver lahmlegt, bevor er überhaupt anfängt, Fehlerantworten zu senden.
Ü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.
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:
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?
So können Sie Queue-Fair verwenden, um Ihren Onsale schön und sicher zu machen, und denken Sie daran, dass Vorsicht immer besser ist als Nachsicht.
2024 The Fair Queue People Ltd. - Alle Rechte vorbehalten.
Teil der Orderly-Familie von Warteschlangenlösungen - OrderlyQ - OrderlyStats - WeQ4U
