Viens worker atrod lietojamu starpniekserveri. Jūs atgriežat tā adresi, izsaucat cancel pārējiem future un gaidāt, ka tīkla darbība apstāsies. Tā var neapstāties.

Future var atcelt pirms tā callable sākuma. Kad pavediens jau izpilda pieprasījumu, tā Future atcelšana nepārtrauc šo socket darbību. Workeram vajadzīga sava ierobežota tīkla darbība un tīrīšanas ceļš.

Svarīgs ir arī izpildītāja mūžs. Izeja no ThreadPoolExecutor konteksta gaida tā darba pabeigšanu. Viena ātra rezultāta atrašana un pēc tam vairāku lēnu worker gaidīšana var padarīt izsaucēja kopējo aizkavi pilnīgi atšķirīgu no uzvarētāja ziņotās latentnes.

Ierobežojiet sacensības pirms to sākuma

  • Ierobežojiet vienlaicīgo pārbaužu skaitu, nevis iesniedziet neierobežotu publisku sarakstu. Bezmaksas starpniekserveru saraksts nodrošina kandidātus pārbaudītāja ievadei, un katra galapunkta protokols tiek saglabāts workeram.
  • Piešķiriet katram pieprasījumam atbilstošu savienojuma un lasīšanas politiku.
  • Piešķiriet izsaucējam kopēju lēmuma budžetu.
  • Definējiet, kas iztukšo vai aizver to worker rezultātus, kuri pārdzīvo lēmumu.

Īsāka gaidīšana uz Future nav tas pats, kas tā pamatā esošā pieprasījuma saīsināšana. Tāpat rezultāta atmešana uzreiz neatbrīvo visus tīkla resursus.

Pirmais veiksmīgais rezultāts arī ir tikai pirmā veiksmīgā pārbaude. Tas var būt atkarīgs no plānošanas, kešotajiem savienojumiem un konkrētā pārbaudes galamērķa. Tas nepierāda, ka galapunkts ir universāli ātrākais vai ka īstais uzdevums izdosies.

Bieži vien neliels paturēts baseins ar neseniem novērojumiem ir vienkāršāks nekā sacensības ar visu sarakstu pirms katras lejupielādes. Izmantojiet īstās operācijas rezultātu, lai atjauninātu ierakstu, kopā ar kontrolētu atkopšanās politiku kļūmēm. Priekšpārbaudei vajadzētu nopelnīt savas izmaksas, nevis no ieraduma dubultot katru uzdevumu.

Saistītie raksti