DocumentDB return "Request Rate ist groß", analysieren auf azurblauen

Question

Ich analysiere gerade auf azurblau (Parse Server auf verwalteten Azure-Dienste), Ich nehme DocumentDB als Datenbank und haben Limit für Anfragen pro Sekunden. Einige Pars Cloud-Funktionen sind groß und die Geschwindigkeit der Anfragen ist zu hoch (sogar für S3 Tier), so bekomme ich diesen Fehler (gesehen mit Visual Studio Team Services (war Visual Studio Online) und Streaming-Protokolle).

error: Uncaught internal server error. { [MongoError: Message: {"Errors":["Request rate is large"]} 

ActivityId: a4f1e8eb-0000-0000-0000-000000000000, Request URI: rntbd://10.100.99.69:14000/apps/f8a35ed9-3dea-410f-a89a-28650ff41381/services/2d8e5320-89e6-4750-a06f-174c12013c69/partitions/53e8a085-9fed-4880-bd90-f6191765f625/replicas/131091039101528218s] 
    name: 'MongoError', 
    message: 'Message: {"Errors":["Request rate is large"]}\r\nActivityId: a4f1e8eb-0000-0000-0000-000000000000, Request URI: rntbd://10.100.99.69:14000/apps/f8a35ed9-3dea-410f-a89a-28650ff41381/services/2d8e5320-89e6-4750-a06f-174c12013c69/partitions/53e8a085-9fed-4880-bd90-f6191765f625/replicas/131091039101528218s' } MongoError: Message: {"Errors":["Request rate is large"]} 

ActivityId: a4f1e8eb-0000-0000-0000-000000000000, Request URI: rntbd://10.100.99.69:14000/apps/f8a35ed9-3dea-410f-a89a-28650ff41381/services/2d8e5320-89e6-4750-a06f-174c12013c69/partitions/53e8a085-9fed-4880-bd90-f6191765f625/replicas/131091039101528218s 
    at D:\home\site\wwwroot\node_modules\mongodb-core\lib\cursor.js:673:34 
    at handleCallback (D:\home\site\wwwroot\node_modules\mongodb-core\lib\cursor.js:159:5) 
    at setCursorDeadAndNotified (D:\home\site\wwwroot\node_modules\mongodb-core\lib\cursor.js:501:3) 
    at nextFunction (D:\home\site\wwwroot\node_modules\mongodb-core\lib\cursor.js:672:14) 
    at D:\home\site\wwwroot\node_modules\mongodb-core\lib\cursor.js:585:7 
    at queryCallback (D:\home\site\wwwroot\node_modules\mongodb-core\lib\cursor.js:241:5) 
    at Callbacks.emit (D:\home\site\wwwroot\node_modules\mongodb-core\lib\topologies\server.js:119:3) 
    at null.messageHandler (D:\home\site\wwwroot\node_modules\mongodb-core\lib\topologies\server.js:397:23) 
    at TLSSocket.<anonymous> (D:\home\site\wwwroot\node_modules\mongodb-core\lib\connection\connection.js:302:22) 
    at emitOne (events.js:77:13) 

Wie wird mit diesem Fehler umgegangen?

Answer 1

TL; DR;

1. Erweitern Sie die alte S3-Kollektion nach dem neuen Preisschema zu einer neuen Einzelkollektion. Dies kann bis zu 10K RU unterstützen (bis zu 2500 RU).
2. Löschen Sie die alte S3-Sammlung und erstellen Sie eine neue partitionierte Sammlung. Benötigt Unterstützung für partitionierte Sammlung in Parse.
3. Implementieren Sie eine Backoff-Strategie in Übereinstimmung mit dem Antwortheader x-ms-retry-after-ms.

Lange Antwort:

Jede Anfrage an DocumentDB gibt einen HTTP-Header mit der Anfrage Gebühr für diese Operation. Die Anzahl der Anfrageeinheiten wird pro Sammlung konfiguriert. Nach meinem Verständnis haben Sie 1 Sammlung der Größe S3, so dass diese Sammlung nur 2500 Request Units pro Sekunde verarbeiten kann.

DocumentDB wird skaliert, indem mehrere Sammlungen hinzugefügt werden. Bei der alten Konfiguration mit S1 -> S3 müssen Sie dies manuell tun, d. H. Sie müssen Ihre Daten mithilfe eines Algorithmus wie konsistentem Hashing, einer Karte oder einem Perhapse-Datum über die Sammlungen verteilen. Mit der neuen Preisgestaltung in DocumentDB können Sie partitionierte Sammlungen verwenden. Indem Sie einen Partitionsschlüssel definieren, wird DocumentDB Ihre Daten für Sie sharden. Wenn Sie anhaltende Raten von RequestRateTooLarge-Fehlern sehen, empfehle ich, die Partitionen zu skalieren. Sie müssen jedoch untersuchen, ob Parse partitissierte Sammlungen unterstützt.

Wenn Sie eine HTTP 429 RequestRateTooLarge erhalten, gibt es auch eine Kopfzeile mit dem Namen x-ms-retry-after-ms: ### wobei ### die Anzahl der Millisekunden angibt, die gewartet werden soll, bevor Sie die Operation wiederholen. Was Sie tun können, ist eine Back-Off-Strategie zu implementieren, die den Vorgang wiederholt. Beachten Sie, dass Sie, wenn Clients während Wiederholungsversuchen auf dem Server hängen, Anforderungswarteschlangen erstellen und den Server blockieren können. Ich empfehle, eine Warteschlange hinzuzufügen, um solche Bursts zu behandeln. Für kurze Anfragen ist dies ein guter Weg, um die Sammlungen zu erweitern.

Answer 2

Ich habe Mlab als externe mongoDB-Datenbank verwendet und konfiguriere die Parse-App in azure, um sie anstelle von documentDB zu verwenden.

Ich muss so viel für "Leistungssteigerung" zu zahlen.