Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Leistungsdaten
Virtual Waiting Room on AWS wurde mit einem Tool namens [Locust](https://locust.io/) ausgelastet. Die Größe der simulierten Ereignisse lag zwischen 10.000 und 100.000 Clients. Die Lasttestumgebung bestand aus der folgenden Konfiguration:
+ Locust 2.x mit Anpassungen für Cloud-Bereitstellungen AWS
+ Vier AWS Regionen (,,,) `us-west-1` `us-west-2` `us-east-1` `us-east-2`
+ 10 `c5.4xlarge` EC2 Amazon-Hosts pro Region (40 insgesamt)
+ 32 Locust-Prozesse pro Host
+ Die simulierten Benutzer verteilten sich gleichmäßig auf die 1.280 Prozesse
Die end-to-end API-Testschritte für jeden Benutzerprozess:
1. Rufen Sie an `assign_queue_num` und erhalten Sie eine Anfrage-ID.
1. Schleife `queue_num` mit der Anforderungs-ID, bis die Warteschlangenposition des Benutzers zurückgegeben wird (kurze Zeit).
1. Schleife `serving_num` solange, bis der zurückgegebene Wert >= die Warteschlangenposition des Benutzers ist (lange Zeit).
1. Rufen Sie selten an`waiting_room_size`, um die Anzahl der wartenden Benutzer abzurufen.
1. Rufen Sie an `generate_token` und erhalten Sie ein JWT zur Verwendung auf der Zielsite.
## Funde
Es gibt keine praktische Obergrenze für die Anzahl der Kunden, die im Wartezimmer bearbeitet werden können.
Die Geschwindigkeit, mit der Benutzer den Warteraum betreten, wirkt sich auf die Quoten für die gleichzeitige Ausführung der Lambda-Funktion für die Region aus, in der sie bereitgestellt wird.
Der Auslastungstest konnte die standardmäßigen API-Gateway-Anforderungslimits von 10.000 Anfragen pro Sekunde mit den verwendeten Caching-Richtlinien nicht überschreiten. CloudFront
Die `get_queue_num` Lambda-Funktion hat eine Aufrufrate von etwa 1:1 im Vergleich zur Rate der eingehenden Benutzer im Wartezimmer. Diese Lambda-Funktion kann bei hoher Anzahl eingehender Benutzer aufgrund von Parallelitätslimits oder Burst-Limits gedrosselt werden. Eine Drosselung, die durch eine große Anzahl von `get_queue_num` Lambda-Funktionsaufrufen verursacht wird, kann sich als Nebeneffekt auf andere Lambda-Funktionen auswirken. Das gesamte System läuft weiter, wenn die Client-Software mit der Wiederholungs-/Back-Off-Logik angemessen auf diese Art von temporärem Skalierungsfehler reagieren kann.
Die vom Core-Stack in einer Standardkontingentkonfiguration konfigurierte CloudFront Verteilung kann einen Warteraum mit 250.000 Benutzern bewältigen, wobei jeder Benutzer die `serving_num` API mindestens jede Sekunde abfragt.