Sensible HTTP-POST-Timeout-Werte, die beim programmatischen Absetzen von Anfragen verwendet werden sollen?

Question

Wenn programmgesteuert HTTP POST-Anforderungen ausgegeben werden, welche Timeout-Werte wären sinnvoll?

In meinem Fall suche ich nach 'vernünftigen' Timeout-Werten bei POST-Anfragen in PHP, dies gilt jedoch für jede Sprache.

Ich muss in der Lage sein, eine Reihe von Anfragen, jeweils zu einer benutzerdefinierten URL. Wenn ich Anfragen fortlaufend anstatt gleichzeitig bearbeiten muss, möchte ich eine sinnvolle Zeit angeben, nach der eine Anfrage als abgelaufen gilt.

PHP default socket timeout ist 60 Sekunden. Dies scheint unnötig lange zu warten, bevor entschieden wird, dass eine Anfrage nicht abgeschlossen wird.

Da dies POST-Anforderungen sind, sollten sie schnell abgeschlossen werden - es gibt keine Daten, die wie bei einer GET-Anforderung abgerufen und zurückgegeben werden können.

Wir sollten in der Lage sein, anzunehmen, die meiste Zeit, dass das Fehlen einer Antwort auf eine Anfrage innerhalb von X Sekunden zu erteilen bedeutet, dass der Host unwahrscheinlich ist deutlich eine Antwort innerhalb einer angemessenen Zeit für Werte von X zur Ausgabe von weniger als 60.

Sicher brauchen Hosts selten mehr als 60 Sekunden, um auf eine einfache POST-Anfrage zu antworten. Benötigen sie selten mehr als 10 Sekunden? 5 Sekunden?

Was könnten für X in der Praxis sinnvolle Werte sein? Begründungen für Vorschläge wären äußerst nützlich.

Answer 1

Ich würde empfehlen, einen Test einzurichten, da zu viele Faktoren beteiligt sind, um einen Wert zu erhalten, der immer sinnvoll ist.

Eine POST-Anfrage sendet Daten zur Verarbeitung. Wie lange dauert die Verarbeitung? Dies wird anwendungs-/datenspezifisch sein.

Wo ist der Host? Der Benutzer liefert die URL, so dass diese unbekannt ist. Wir können nicht wissen, wie der Verkehr zwischen Ihrer Anwendung und dem Host ist. Wir können die Serverlast des Hosts nicht kennen.

Im Wesentlichen gibt es keine universelle sinnvolle Zeitüberschreitung. Sie müssen Ihr eigenes Urteilsvermögen basierend auf Ihren spezifischen Bedürfnissen verwenden. Richten Sie einen Test ein und verwenden Sie diesen, um Ihre Grenzen zu bestimmen.

Answer 2

Die meisten Bibliotheken haben eine Verbindungszeitüberschreitung und eine Lesezeitüberschreitung. Das heißt, das Zeitlimit zwischen dem Versuch, eine Verbindung mit dem Remote-Server herzustellen, und dem Timeout nach dem Senden der Anfrage, dass sie auf eine Antwort warten sollten.

Wenn dies ein lokaler Webdienst ist, würde ich das Verbindungszeitlimit auf 1 Sekunde oder niedriger einstellen, wenn Ihre Bibliothek dies unterstützt. Wenn der Remotedienst, zu dem Sie eine Verbindung herstellen, nicht verfügbar ist, sollten Sie sofort eine Antwort an den Benutzer senden, damit alle Worker-Threads auf diesem Remotedienst blockieren können, wodurch andere Upstream-Fehler verursacht werden.

Wie für die Lese-Timeout, das ist kniffliger, Sie brauchen es niedrig, so dass Sie nicht erschöpfen Ihren Pool von Arbeitern, die auf den Remote-Dienst warten zurück, aber Sie wollen es auch nicht niedrig, dass es die Verbindung vor dem Lesen einer Antwort schließt. Das müssen Sie testen und dann als Metrik verfolgen, wenn Ihr System in Produktion ist.