Zum Hauptinhalt springen
Fähigkeit

Warteraum

Wenn der Andrang größer ist als die Anwendung, gehört die Warteschlange davor — geordnet, fair und mit einer Nummer, die der Besucher tatsächlich sieht.

TR7 Waiting Room lässt Besucher in dem Tempo ein, das Ihre Anwendung bedienen kann, und hält den Rest in einer geordneten Warteschlange auf der Delivery-Plattform. Zwei Obergrenzen erledigen die Arbeit: wie viele Besucher gleichzeitig drinnen sein dürfen und wie schnell neue hinzukommen dürfen. Alles Weitere — die gebrandete Seite, die Position, die geschätzte Wartezeit, die Ausnahme für verifizierte Suchmaschinen — existiert, damit die Warteschlange etwas ist, das man aushält, und nicht etwas, das man verlässt.

Pro Dienst
Jeder veröffentlichte Dienst hat eigene Obergrenze und eigene Warteseite
0
Zeilen Anwendungscode, die für eine vorgelagerte Warteschlange geändert werden
Monitor
Modus, der die Warteschlange vor dem Ereignis dimensioniert statt währenddessen

Ein Launch-Tag fällt nicht langsam aus. Er fällt auf einmal aus.

Kapazitätsplanung unterstellt, dass Verkehr mit einer Rate eintrifft. Verkaufsstart, Kampagnenlaunch, Prüfungsergebnisse und Terminfenster treffen nicht mit einer Rate ein — sie treffen in einem Augenblick ein. Die Anwendung wird dabei nicht höflich langsamer: der Verbindungspool füllt sich, die Datenbank staut, die Antwortzeiten steigen, und Nutzer laden neu, was genau die Last verdoppelt, die das Problem verursacht hat.

Die üblichen Antworten machen es schlimmer. Autoscaling fügt Instanzen hinzu, nachdem die Spitze längst da und die Datenbank längst der Engpass ist. Rate Limiting weist Anfragen ab — für jemanden, der für ein Konzertticket ansteht, nicht von einer kaputten Website zu unterscheiden. Beides hinterlässt denselben Eindruck: In dem Moment, in dem Sie am meisten bereit sein wollten, waren Sie es nicht.

Ein Warteraum ändert die Form des Problems. Der Andrang wird weder abgewiesen noch verworfen, sondern geordnet. Die Anwendung bedient die Zahl, die sie gut bedienen kann, alle anderen halten einen Platz mit Position und Schätzung, und die Plattform lässt den Nächsten in dem Moment ein, in dem ein Platz frei wird.

Unser Ansatz

Die Warteschlange läuft auf der Delivery-Plattform vor der Anwendung — sie steht also noch, wenn die Anwendung längst am Limit ist. Kein Anwendungscode ist daran beteiligt, jemanden einzulassen, zu halten oder freizugeben.

Eine Obergrenze, die die Anwendung wirklich bedienen kann

Legen Sie fest, wie viele Besucher gleichzeitig in einen veröffentlichten Dienst dürfen. Die Zahl kommt daher, was die Anwendung nachweislich gut verkraftet, nicht daher, was die Hardware theoretisch durchlassen könnte.

Eine Schranke für das Ankunftstempo, nicht nur für die Menge

Eine eigene Obergrenze begrenzt, wie viele neue Besucher pro Minute eintreten dürfen. Genau das schützt ein Backend, das eine große, gleichmäßige Population verkraftet und zusammenbricht, wenn zehntausend Menschen in derselben Sekunde ankommen.

Monitor-Modus — die Kapazität wird vor dem Ereignis gefunden

Betreiben Sie den Warteraum im Monitor-Modus: Er zählt, was passiert wäre, ohne jemanden zurückzuhalten. Sie dimensionieren die Warteschlange an Ihrem eigenen Verkehr, an einem gewöhnlichen Tag, und kommen mit einer Zahl zum Ereignis, der Sie vertrauen.

Verifizierte Bots belegen keinen Platz

Verifizierte Suchmaschinen und Monitoring-Probes werden erkannt und ausgenommen, sodass Indexierung und Verfügbarkeitsprüfungen während des Ereignisses weiterlaufen und kein Platz an Verkehr geht, der ohnehin nichts kauft.

Fähigkeiten

Alles Folgende wird pro veröffentlichtem Dienst auf demselben Bildschirm wie die übrige Traffic-Policy konfiguriert, und jede Änderung greift per Hot Reload — auch während des Ereignisses.

Maximale gleichzeitige Besucher, je veröffentlichtem Dienst

Verschiedene Anwendungen haben verschiedene Grenzen, und eine Appliance kann für jede davon gleichzeitig einen eigenen Warteraum betreiben. Die Obergrenze ist eine Eigenschaft des Dienstes, nicht der Box.

Neue Besucher pro Minute — Spitzenschutz

Die Zutrittsschranke ist unabhängig von der Concurrency-Grenze. Ein Pool, dem 20.000 Menschen drinnen nichts ausmachen, kann trotzdem zerstört werden, wenn 20.000 auf einmal ankommen; dieser Regler trennt beide Fälle.

Bedingte Warteseiten — nur wo es zählt

Die Warteschlange wird per Bedingung angewandt: Checkout- und Ticketpfade sind geschützt, Katalog, Hilfeseiten und Statusseite bleiben offen. Der Besucher wartet auf das Knappe, nicht auf die ganze Website.

Position und geschätzte Wartezeit, für den Besucher sichtbar

Eine Warteschlange ohne Nummer ist von einem Hänger nicht zu unterscheiden. Die Warteseite zeigt, wo der Besucher steht und wie lange es voraussichtlich dauert — das ist der Unterschied zwischen Warten und Gehen.

Der Platz bleibt — Neuladen kostet ihn nicht

Die Position hängt an der Sitzung des Besuchers: Neuladen, ein Verbindungsabbruch oder der Wechsel von Mobilfunk zu WLAN schickt niemanden ans Ende. Refresh-Stürme hören auf, selbst verursachter Schaden zu sein.

Ihre eigene Warteseite

Die Seite ist eine Vorlage, die Sie kontrollieren — Ihre Marke, Ihre Sprache, Ihre Botschaft — ausgeliefert von der Plattform, selbst wenn die Anwendung dahinter voll ausgelastet ist.

Einlass in dem Moment, in dem ein Platz frei wird

Sobald Sitzungen enden, werden die nächsten Besucher automatisch freigegeben. Niemand wartet auf einen Timer, der nicht mehr zur Realität passt.

Live-Sicht während des Ereignisses

Warteschlangentiefe, Einlässe pro Minute, durchschnittliche Wartezeit und Abbruchquote stehen während des Ereignisses auf dem Bildschirm — die Entscheidung, die Obergrenze zu heben oder zu senken, fällt anhand von Belegen.

Operative Tiefe

Ein Warteraum ist nur so gut wie sein Verhalten in den unangenehmen Fällen — ein Failover mitten im Ereignis, eine Bot-Flotte in der Schlange, ein Besucher mit wackliger Verbindung.

01

Die Warteschlange liegt auf der Plattform, nicht in der Anwendung

Kein Agent, keine Bibliothek, keine Codeänderung und kein separater Warteschlangendienst, den man betreiben muss. Die Anwendung erfährt nie, dass ein Warteraum existiert; sie sieht schlicht nie mehr Verkehr, als sie bedienen kann.

02

Faire Reihenfolge, an die Sitzung gebunden

Eingelassen wird nach Reihenfolge des Eintreffens, und die Position folgt der Sitzung des Besuchers statt einer IP-Adresse — ein Firmen-NAT, ein Carrier-CGNAT oder eine geteilte Büroleitung stellt nicht alle hintereinander.

03

Spielt mit dem übrigen Schutz zusammen

Bot-Scoring läuft vor der Warteschlange, automatisierter Verkehr wird also behandelt statt eingereiht. Rate Limiting gilt weiterhin für alle drinnen. Der Warteraum verwaltet den ehrlichen Andrang; er soll keine Sicherheitskontrolle sein.

04

Übersteht ein Failover

Der Zustand der Warteschlange wird im Cluster repliziert: Ein Knotenausfall während des Verkaufsstarts setzt die Schlange nicht zurück. Das Ereignis läuft auf dem verbliebenen Knoten weiter, alle Positionen bleiben erhalten.

05

Verhalten bei Neuladen, neuen Tabs und geteilten Geräten

Ein zweiter Tab tritt demselben Platz bei, statt einen zweiten zu belegen. Explizite Regeln decken Sitzungsablauf und Abbruch ab, sodass Plätze von Besuchern, die gegangen sind, in die Schlange zurückkehren.

06

Während des Ereignisses ein- und ausschaltbar

Die gesamte Funktion ist eine Hot-Reload-Änderung. Sie lässt sich Minuten vor dem Verkaufsstart aktivieren und in dem Moment deaktivieren, in dem die Spitze vorbei ist — ohne eine Verbindung zu verlieren.

Anwendungsszenarien

Verkaufsstart und Ticketing

Konzerte, Spiele und Reiseverkäufe pressen den Jahresverkehr in neunzig Sekunden. Der Warteraum macht aus einer nicht bedienbaren Spitze eine geordnete Schlange, und jeder Besucher behält einen sichtbaren Platz.

Produkt-Launches und Kampagnen

Eine funktionierende Kampagne ist auf Netzwerkebene von einem Angriff nicht zu unterscheiden. Der Warteraum lässt Marketing erfolgreich sein, ohne dass die Infrastruktur den ganzen Erfolg in einer Sekunde aufnehmen muss.

Antragsfenster im öffentlichen Sektor

Prüfungsergebnisse, Steuerfristen und Terminfreigaben werden einer ganzen Bevölkerung auf die Minute genau angekündigt. Eine Schlange mit sichtbarer Position ist zugleich die fairste Antwort, die man Bürgern geben kann.

Zahltag- und Monatsendspitzen im Banking

Vorhersehbare, wiederkehrende Spitzen rechtfertigen es nicht, die Plattform dauerhaft auf die schlimmste Stunde des Monats auszulegen. Der Warteraum deckt die Spitze ab, die Plattform bleibt auf den normalen Tag ausgelegt.

Häufig gestellte Fragen

Worin unterscheidet sich das von Rate Limiting?
Rate Limiting weist Anfragen oberhalb einer Schwelle ab; der Besucher bekommt einen Fehler und weiß nicht, was er tun soll. Ein Warteraum nimmt alle an und ordnet sie — niemand wird abgewiesen, jedem wird gesagt, wo er steht und wie lange es ungefähr dauert. Beides hat seinen Platz und beides läuft zusammen: Rate Limiting befasst sich mit Missbrauch, der Warteraum mit legitimer Nachfrage, die schlicht größer ist als die Anwendung.
Muss die Anwendung geändert werden?
Nein. Die Warteschlange läuft auf der Delivery-Plattform vor der Anwendung: keine Bibliothek zu integrieren, kein Agent zu installieren, kein Warteschlangendienst zu betreiben. Die Anwendung sieht immer nur den Verkehr, der eingelassen wurde.
Wie wählen wir die richtige Concurrency-Zahl?
Betreiben Sie den Warteraum zuerst im Monitor-Modus. Er zählt an Ihrem eigenen Verkehr, was eingereiht worden wäre, ohne jemanden zurückzuhalten — so setzen Sie die Obergrenze auf Belege einer gewöhnlichen Woche statt auf eine Schätzung unter Druck am Tag selbst.
Was passiert, wenn ein Besucher neu lädt oder die Verbindung verliert?
Der Platz hängt an der Sitzung, nicht an der Anfrage: Neuladen, ein Abbruch oder ein Netzwechsel erhalten die Position. Das ist wichtiger, als es klingt — sonst laden besorgte Besucher neu, das Neuladen vervielfacht die Last, und die Warteschlange verursacht genau das Problem, gegen das sie installiert wurde.
Bleiben Suchmaschinen und Monitoring in der Schlange stecken?
Nein. Verifizierte Suchmaschinen und Monitoring-Probes werden erkannt und ausgenommen; Indexierung und Verfügbarkeitsprüfungen laufen während des Ereignisses normal weiter, ohne einen Platz zu belegen.
Was passiert mit der Warteschlange, wenn während des Ereignisses ein Clusterknoten ausfällt?
Der Zustand der Warteschlange wird im Cluster repliziert, der verbliebene Knoten führt dieselbe Schlange mit erhaltenen Positionen fort. Ein Failover mitten im Verkaufsstart wird nicht zum zweiten Vorfall.

Bereit sein für die Minute, die das Quartal entscheidet

Concurrency-Obergrenze, Zutrittsschranke und gebrandete Warteschlange — pro Dienst konfiguriert, vor dem Ereignis im Monitor-Modus dimensioniert. Lassen Sie es uns an Ihrem Verkehr einrichten.