Праверкі Python-проксі: чаму Future.cancel() пакідае патокі працаваць

Адзін worker знаходзіць прыдатны проксі. Вы вяртаеце яго адрас, выклікаеце cancel для іншых future і чакаеце, што сеткавая актыўнасць спыніцца. Гэта можа не адбыцца.

Future можна адмяніць да запуску яго callable. Калі паток ужо выконвае запыт, адмена яго Future не перарывае гэтую аперацыю з сокетам. Worker патрэбна ўласная абмежаваная сеткавая аперацыя і шлях ачысткі.

Тэрмін жыцця executor таксама мае значэнне. Выхад з кантэксту ThreadPoolExecutor чакае завяршэння яго працы. Знайсці адзін хуткі вынік, а потым чакаць некалькіх павольных worker, можа зрабіць агульную затрымку выклікальніка зусім не падобнай на зарэгістраваную латэнтнасць пераможцы.

Абмяжуйце гонку да яе пачатку

• Абмяжуйце колькасць адначасовых праворак замест падачы неабмежаванага публічнага спісу. Бясплатны спіс проксі дае кандыдатаў для ўводу правяральніка, прычым пратакол кожнай канцавой кропкі захоўваецца для worker.
• Дайце кожнаму запыту адпаведную палітыку злучэння і чытання.
• Дайце выклікальніку агульны бюджэт рашэння.
• Вызначце, хто злівае або закрывае вынікі worker, якія перажываюць рашэнне.

Менш чакаць Future — гэта не тое самае, што зрабіць яго асноўны запыт карацейшым. Гэтак жа адмова ад выніку не вызваляе адразу ўсе сеткавыя рэсурсы.

Першы паспяховы вынік — гэта таксама толькі першая паспяховая праверка. Ён можа залежаць ад планавання, кэшаваных злучэнняў і канкрэтнага прызначэння праверкі. Ён не даказвае, што канцавая кропка ўніверсальна самая хуткая або што рэальная задача ўдасца.

Часта невялікі захаваны пул з нядаўнімі назіраннямі прасцейшы, чым гонка па ўсім спісе перад кожным спампоўваннем. Выкарыстоўвайце вынік рэальнай аперацыі для абнаўлення запісу, з кантраляванай палітыкай аднаўлення пасля збояў. Папярэдняя праверка павінна апраўдваць свае выдаткі, а не падвойваць кожную задачу па звычцы.