Üks worker leiab kasutatava puhverserveri. Tagastate selle aadressi, kutsute teistel future'itel välja cancel ja eeldate, et võrgutegevus lakkab. See ei pruugi lakkada.

Future'i saab tühistada enne, kui selle callable algab. Kui lõim juba täidab päringut, ei katkesta selle Future'i tühistamine seda socket-operatsiooni. Worker vajab oma piiratud võrguoperatsiooni ja puhastusteed.

Ka täitja eluiga on oluline. ThreadPoolExecutor kontekstist lahkumine ootab selle töö lõppemist. Ühe kiire tulemuse leidmine ja seejärel mitme aeglase workeri ootamine võib muuta kutsuja koguhilinemise täiesti erinevaks võitja teatatud latentsusest.

Piirake võidujooks enne selle algust

  • Piirake samaaegsete kontrollide arvu, selle asemel et esitada piiramatu avalik nimekiri. Tasuta puhverserverite nimekiri pakub kontrollijale kandidaate, kusjuures iga lõpp-punkti protokoll säilitatakse workeri jaoks.
  • Andke igale päringule sobiv ühenduse ja lugemise poliitika.
  • Andke kutsujale üldine otsustuseelarve.
  • Määrake, kes tühjendab või sulgeb nende workerite tulemused, kes otsusest kauem elavad.

Future'i vähem ootamine ei ole sama, mis selle aluspäringu lühemaks muutmine. Samuti ei vabasta tulemusest loobumine kohe kõiki võrguresursse.

Esimene edukas tulemus on ka ainult esimene edukas kontroll. See võib sõltuda ajastamisest, vahemällu salvestatud ühendustest ja konkreetsest kontrollisihtkohast. See ei tõesta, et lõpp-punkt on universaalselt kiireim või et tegelik ülesanne õnnestub.

Sageli on väike alles hoitud varam koos värskete vaatlustega lihtsam kui kogu nimekirjaga võidujooks enne iga allalaadimist. Kasutage tegeliku toimingu tulemust kirje värskendamiseks koos tõrgete jaoks mõeldud kontrollitud taastamispoliitikaga. Eelkontroll peaks oma kulud ära teenima, mitte harjumusest iga ülesannet kahekordistama.

Seotud artiklid