Bokanta prokura-poola serĉo povas haltigi Scrapy

La rampilo havas sufiĉe da samtempaj petoj agorditaj. Ĝi tamen paŭzas ĉiam, kiam ĝi petas al la prokura poolo alian adreson. Aldoni pli da prokuroj ne tuŝas tiun paŭzon.

Komuna middleware-ŝablono vokas requests.get(pool_url) ene de process_request(). Tio estas sinkrona reta operacio sur vojo, kiu devus kunlabori kun la nesinkrona motoro de Scrapy. Dum la voko atendas, ĝi povas haltigi nerilatan laboron sur la sama eventbukla fadeno.

Estas du petoj en la tasko

Unu peto akiras finpunkton de la poolservo. La alia uzas tiun finpunkton por kontakti la celon. Mezuru kaj raportu ilin aparte. Malrapida pool-API povas igi ĉiun elektitan prokuron ŝajni malrapida antaŭ ol la aplikaĵo eĉ konektiĝis al ĝi.

Uzu nesinkronan malkovran integriĝon subtenatan de la instalita versio de Scrapy, aŭ akiru kaj refreŝigu limigitan lokan finpunktaron ekster la kritika vojo de ĉiu peto. Se blokanta laboro devas esti delokigita, donu al tiu plenumilo proprajn limojn kaj tempoliman pritraktadon; senlima vico nur translokas la prokraston.

Ne eldonu aŭtomate alian malkovran vokon por ĉiu peto. Mallongdaŭra kaŝmemoro aŭ luata aro povas malpliigi la dependon de la poolservo, kondiĉe ke ĝia vivdaŭro konvenas al la reala finpunkta politiko de la servo.

Difinu, kion signifas malsukcesa serĉo

Malplena aŭ malsukcesa respondo de la poolo ne devus silente forigi la prokurajn metadatumojn kaj permesi rektan peton. Elektu klaran rezulton: atendi ene de la taska buĝeto, malsukcesi, aŭ uzi aprobitan kaŝitan finpunkton.

Tenu ankaŭ la propran vojon de la pool-API libera. Se ĝi estas interna servo, sendi ĝian privatan hostonomon tra ĝuste tiu prokuro, kiun ĝi helpas elekti, povas krei cirkulan dependon.

Post kiam malkovro funkcias sen bloki nerilatan laboron, ekzamenu la ordinaran prokuran transakcion. Tiuj estas apartaj riparoj, kaj ilia tempomezuro meritas apartajn kampojn en la protokolo.