Ein Worker findet einen nutzbaren Proxy. Sie geben seine Adresse zurück, rufen cancel für die anderen Futures auf und erwarten, dass die Netzwerkaktivität aufhört. Das muss nicht passieren.

Ein Future kann abgebrochen werden, bevor sein Callable startet. Sobald ein Thread bereits eine Anfrage ausführt, unterbricht das Abbrechen seines Futures diesen Socket-Vorgang nicht. Der Worker braucht eine eigene begrenzte Netzwerkoperation und einen Aufräumpfad.

Auch die Lebensdauer des Executors spielt eine Rolle. Den Kontext eines ThreadPoolExecutor zu verlassen, wartet auf dessen Abschluss. Ein schnelles Ergebnis zu finden und dann auf mehrere langsame Worker zu warten, kann die Gesamtverzögerung des Aufrufers völlig anders aussehen lassen als die gemeldete Latenz des Gewinners.

Das Rennen begrenzen, bevor es beginnt

  • Begrenzen Sie die Anzahl gleichzeitiger Prüfungen, statt eine unbegrenzte öffentliche Liste einzureichen. Die kostenlose Proxy-Liste liefert Kandidaten für die Eingabe des Prüfers, wobei das Protokoll jedes Endpunkts für den Worker erhalten bleibt.
  • Geben Sie jeder Anfrage eine passende Verbindungs- und Leserichtlinie.
  • Geben Sie dem Aufrufer ein Gesamtbudget für die Entscheidung.
  • Legen Sie fest, wer Ergebnisse von Workern abführt oder schließt, die die Entscheidung überleben.

Kürzer auf ein Future zu warten ist nicht dasselbe, wie seine zugrunde liegende Anfrage zu verkürzen. Ebenso gibt das Verwerfen des Ergebnisses nicht sofort jede Netzwerkressource frei.

Das erste erfolgreiche Ergebnis ist auch nur die erste erfolgreiche Prüfung. Es kann von der Planung, zwischengespeicherten Verbindungen und dem konkreten Prüfziel abhängen. Es belegt nicht, dass der Endpunkt universell der schnellste ist oder dass die eigentliche Aufgabe gelingen wird.

Oft ist ein kleiner gehaltener Pool mit aktuellen Beobachtungen einfacher, als vor jedem Download die gesamte Liste zu überholen. Nutzen Sie das Ergebnis der echten Operation, um den Datensatz zu aktualisieren, mit einer kontrollierten Wiederherstellungsrichtlinie für Fehler. Der Preflight sollte seine Kosten verdienen, statt jede Aufgabe aus Gewohnheit zu verdoppeln.

Ähnliche Artikel