Best Practices für Web-Service-Timeouts

Question

Gibt es einen Artikel/ein Buch, in dem Obergrenzen für Entwurfsgrenzen für WS-Zeitüberschreitungen definiert sind? Haben Sie eine Zeitüberschreitung auf dem Server oder empfehlen Sie die Client-spezifischen Timeouts?

Gibt es ein gemeinsam Best Practice wie „nie WS entwerfen, die länger als 60 Sekunden dauern können, verwenden Sie ein asynchrones Token Muster“

ich zu wissen, interessiert bin, was Sie tun oder auch Ihrer Meinung.

Answer 1

Diese Frage und die zu verknüpften diejenigen in Antworten darauf, helfen könnten: Is there some industry standard for unacceptable webapp response time?

Etwas tangential auf Ihre Frage (keine Zeitintervalle, sorry), aber ich vermute, für Ihre Arbeit nützlich: Eine gemeinsame Ansatz zu Timeouts ist es, sie mit "Back-Off" Timern auszugleichen.
Es geht ungefähr so: Das erste Mal, dass ein Dienst ausläuft, mach dir keine Sorgen darüber. Das zweite Mal in Folge ein Service-Zeitlimit, nicht stören, rufen Sie es für N Sekunden. Das dritte Mal in Folge ein Service-Timeout, rufen Sie nicht für N + 1 Sekunden. Dann N + 2, N + 3, N + 5, N + 8, usw., bis Sie eine maximale Grenze M erreichen.

Der Timeout-Zähler wird zurückgesetzt, wenn Sie eine gültige Antwort erhalten.

Ich benutze eine Fibbonacci-Sequenz, um die "Back-Off" -Zeit hier zu verlängern, aber natürlich können Sie jede andere geeignete Funktion verwenden - der Punkt ist, wenn der Service, den Sie versuchen, Sie zeitlich steuert, Sie " Glaube "darin wird kleiner und kleiner, so dass Sie weniger Ressourcen ausgeben, um zu versuchen, und klopfen an der Tür seltener. Dies kann dazu beitragen, dass der Dienst am anderen Ende, der einfach überlastet und neu angefordert werden kann, nur die Situation verschlimmert und Ihre Reaktionszeit verlängert wird, da Sie nicht auf einen Dienst warten müssen, der wahrscheinlich nicht antwortet.

Answer 2

Nehmen Sie die Menge der Daten, die Sie über Ihren Web-Service übertragen, und sehen Sie, wie lange der Prozess dauert.

Fügen Sie dieser Nummer 60 Sekunden hinzu und testen Sie sie.

Wenn Sie bei einer guten Verbindung Timeout erreichen können, fügen Sie weitere 30 Sekunden hinzu.

spülen und wiederholen.

Answer 3

Im Allgemeinen nehmen wir die erwartete Antwortzeit für diesen Web-Service (wie in unserer Schnittstellenspezifikation dokumentiert) und fügen ihm 30 Sekunden hinzu.

Dann überwachen wir die Protokolle während der UAT, um festzustellen, ob Muster vorhanden sind (z. B. bestimmte DB-Aufrufe benötigen eine lange Zeit), und ändern sie gegebenenfalls.

Answer 4

Dieses Zeug über 30 Sekunden Timeouts ist lächerlich, IMO. Ihre Timeouts sollten ungefähr 3 Sekunden betragen. Ja. Drei. Die Nummer nach zwei und vor vier. Wenn Sie eine Anwendung basierend auf einer SOA erstellen, dann DEFINITIV 3 Sekunden oder weniger.

Denken Sie darüber nach ... der Benutzer Ihrer App erwartet eine Gesamtansprechzeit von etwa fünf Sekunden oder weniger (vorzugsweise etwa drei). Wenn JEDER INDIVIDUELLE SERVICEAUFRUF mehr als ein paar * Millisekunden * benötigt, um zurück zu kommen, wird Ihnen abgesoffen. Warten 30+ Sekunden für einen Dienst zurückzukehren ist eine Ewigkeit. Der Benutzer wird nie so lange warten.Plus, wenn Sie wissen, dass sie im Bereich von weniger als einer Sekunde zurückkommen sollen, was ist der Punkt des Wartens auf einen weiteren Fehler oder mehr Sekunden auf einen Fehlerzustand zu warten; es wird nicht magisch funktionieren, wenn es nicht vor 28 Sekunden war. Wenn Ihre Anwendung eine durchschnittliche Antwortzeit von unter einer Sekunde bis über 30 Sekunden aufweist, wurde etwas falsch entworfen. Sie könnten über etwas Caching oder etwas nachdenken.