Gibt es einen Artikel / ein Buch, der Obergrenzen für das Design für WS-Timeouts definiert? Haben Sie eine Zeitüberschreitung auf dem Server oder empfehlen Sie die Client-spezifischen Timeouts?
Gibt es eine gängige Best Practice wie "Niemals WS entwerfen, die länger als 60 Sekunden dauern kann, verwenden Sie ein asynchrones Token-Muster"
Ich bin interessiert zu wissen, was Sie tun oder Ihre Meinung zu.
Diese Frage und die damit verknüpften Antworten könnten helfen: Gibt es einen Industriestandard für nicht akzeptable Webapp-Antwortzeiten?
Etwas tangential zu Ihrer Frage (keine Zeitintervalle, tut mir leid), aber ich vermute, dass es nützlich für Ihre Arbeit ist:
Ein üblicher Ansatz für Timeouts ist es, sie mit "Back-Off" -Timern auszugleichen.
Es geht ungefähr so:
Wenn ein Dienst zum ersten Mal ausfällt, machen Sie sich keine Sorgen.
Das zweite Mal in Folge, dass ein Dienst ausfällt, nicht stören, es für N Sekunden zu nennen.
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 erreicht haben.
Der Zeitüberschreitungszähler wird zurückgesetzt, wenn Sie eine gültige Antwort erhalten.
Ich benutze eine Fibbonacci-Sequenz, um den "Back-Off" -Zeitpunkt hier zu erhöhen, aber natürlich können Sie jede andere geeignete Funktion verwenden - der Punkt ist, wenn der Service, den Sie versuchen, Sie zeitlich versetzt, Sie "glauben "In ihm werden immer kleiner, so dass Sie weniger Ressourcen ausgeben, um zu versuchen, und seltener an die Tür klopfen. 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.
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 Nutzer Ihrer App erwartet eine Gesamtansprechzeit von etwa fünf Sekunden oder weniger (vorzugsweise etwa drei Sekunden). 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. Und wenn Sie wissen, dass sie im Bereich von weniger als einer Sekunde zurückkommen sollen, müssen Sie auf weitere 30 oder mehr Sekunden warten, um einen Fehler zu signalisieren. 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.
Nehmen Sie die Menge der Daten, die Sie über Ihren Web-Service übertragen, und sehen Sie, wie lange der Prozess dauert.
Fügen Sie 60 Sekunden zu dieser Zahl 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.
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.
Tags und Links wcf timeout web-services scalability