September 14
Ilang linggo kaming naghintay para sa araw na ito. Nag-dilim ang aming residential proxy provider dahil sa isang billing failure noong Hulyo, at sa loob ng dalawang buwan, lumalaking bahagi ng aming 1,375 sources ang gumagana nang hina o hindi gumagana nang buo — mga fetch na nag-timeout, mga IP na na-block sa gitna ng session, ang klase ng unti-unting pagkatas na hindi lumalabas bilang isang outage kundi bilang paliit na bilang na hindi mapapansin ng kahit sino hanggang sa maging kahiya-hiya na ito. Nag-renew kami. Bagong pool, 20,000 rotating residential session lines, pinasuri bawat exit bago ito palapitin sa production. 100% ng probe ang pumasa. AE, DE, JP — lahat live, lahat malinis.
Kaya nagpatakbo kami ng supervised crawl, ang tipo kung saan talagang nakakabantay ang isang tao sa dashboard sa halip na magtiwala sa cron. Inaasahan ko ang kabaligtaran ng isang sakuna.
Ang nakuha namin ay isang database na nawalan ng 84,401 rows sa isang pass lamang, kasama ang 102 sources na bumagsak nang higit sa 25% mula sa naunang snapshot. Mas masahol pa sa dalawang buwang kagutuman sa proxy na kakaayos pa lang namin.
Ang maling teorya, sa madaling sabi
Ang unang instinct ko — at aaminin ko itong tapat — ay na mas masahol pala ang bagong pool kaysa sa ipinahiwatig ng probe. Baka na-rate-limit ang mga session IP sa gitna ng crawl sa isang paraang hindi mahuhuli ng isang one-shot probe. Makatwirang teorya ito. Mali rin ito, at ang paniniwala dito kahit kalahating araw lang ay nagpakain sa oras na wala naman kami, dahil nananatiling paused ang crawl cron habang dini-debug mo ang isang teoryang ganito — ayaw mong mapatungan ng isang masamang pass ang isang magandang snapshot habang nanghuhula ka pa.
Ang palatandaan na sumira sa teorya ay dubizzle. Isa sa aming pinakamataas-ang-volume na UAE source, aktwal na na-fetch nito ang 32,595 listings sa run na iyon — isang talagang malusog na bilang, malinaw na gumagana ang proxies — at pagkatapos ay itinapon ang halos lahat nito. Hindi nabigo sa pag-fetch. Na-fetch, at itinapon.
Setyembre 16: natagpuan ang tunay na bug
Dito ito tumigil sa pagiging kuwento tungkol sa proxy at naging kuwento tungkol sa row-replacement. Sine-snapshot ng aming persistence layer ang bawat source bilang isang kumpletong pag-overwrite sa <site>_cars_for_sale.csv sa bawat pass — mga kasalukuyang listing lang, palitan ang buong table. Tama ang ganitong gawi kapag natapos ang isang crawl. Nagiging sakuna ito kapag nag-timeout ang isang crawl sa kalagitnaan at isusulat ng scraper kung ano man ang bahagyang batch na nakolekta nito na parang ito ang kumpletong snapshot. Ang isang source na karaniwang may 9,000 live listing ay na-overwrite ng 1,200 na na-scrape nito bago maubos ang oras, at ang natitirang 7,800 ay naglaho — hindi dahil nabenta ang mga kotse, kundi dahil nagpasya ang sarili naming code na ang hindi kumpletong fetch ay kumpleto.
Hindi kami niloloko ng proxies. Ang retry logic ang problema, at matagal na itong palihim na sira, natatakpan lang ng isang mas malusog na pool na dating nakakatapos ng mga fetch bago pa man magkabuluhan ang sweep.
Ganito talaga ang naging kabayaran ng sweep na iyon, kapag kinuwenta namin:
| Lumang retry sweep | Naayos na sweep | |
|---|---|---|
| Retries kada proxy | 3 | 1 |
| Delay kada pagsubok | 1s | — |
| Epektibong hangganan sa isang 50-proxy pool | ~56 minuto kada URL | 120-segundong kabuuang budget |
| Gawi sa timeout | isusulat ang bahagyang batch bilang buong snapshot | laktawan ang source, panatilihin ang naunang snapshot |
Limampu't anim na minuto bago sumuko sa isang URL lang. I-multiply mo ito sa isang crawl na sumasaklaw sa mahigit isanlibong sources, at makukuha mo mismo ang klase ng tahimik, hindi pantay na pagkalat ng pagkabigo na nakita namin — ilang sources ang okay, 102 sa mga ito ang nalupig, walang anuman sa logs na sumisigaw ng "proxy outage" dahil, teknikal, wala naman talaga.
Setyembre 25: ang ayos, at ang bahaging mahalaga sa iyo
Ang patch na inilabas pagkaraan ng siyam na araw ay gumawa ng dalawang hindi kaakit-akit na bagay. Nilimitahan nito ang matematika ng retry para ang isang natigil na fetch ay mabigo kaagad sa halip na kainin ang halos isang oras, at — ito ang talagang pumipigil sa pagkawala ng data — hindi na papalitan ng isang bahagyang fetch ang buong set ng rows. Kung ang isang source ay nakakuha lang ng 1,200 sa karaniwang 9,000 listing nito, pananatilihin namin ang naunang kumpletong snapshot sa halip na patungan ito ng isang pira-piraso. Sa parehong araw, dumating ang ikalawang pagbabago na nagsusulat ng isang nakikitang CRAWL_PAUSED flag na sinusuri ng aming monitoring bago ito mag-page sa kahit sino tungkol sa isang pagbagsak — para ang isang sinadyang pag-pause ay babasahin bilang pag-pause, hindi bilang alerto.
Bakit dapat alalahanin ito ng isang mambabasa na namimili ng segunda-manong Hyundai? Dahil ang mga below-market flag na inilalathala namin — 12,823 sa mga ito ang live sa site sa linggong ito — ay tapat lamang kung ang cohort na pinaghahambing namin sa isang listing ay ang totoo at kumpletong pamilihang rehiyonal at hindi isang pira-pirasong fragment nito dulot ng timeout. Ang isang deal badge na binuo laban sa isang snapshot na nawalan ng tatlong-kapat ng kanyang comparison set ay hindi isang deal badge, ito ay ingay na nagsusuot ng berdeng label. Mas pipiliin naming i-pause ang isang crawl sa loob ng siyam na araw kaysa ilathala iyon.
Ang dataset ngayon ay nasa 1,108,535 listings sa 73 rehiyon at 1,375 sources — mas malaki kaysa dati bago magsimula ang lahat ng ito, naayos na ang proxies at sarado na ang row-replacement bug. Pero ang numero na laging babalikan ko ay hindi ang kabuuan. Ito ay 84,401 — ang agwat sa pagitan ng isang crawl na mukhang malusog sa antas ng proxy at isang talagang malusog nga.
