0x00
Veebikraapija (tuntud ka kui ämblik, veebibot, FOAF kogukonnas sagedamini kui veebijälitaja) on programm või skript, mis automaatselt kraabib infot World Wide Webi kohta vastavalt teatud reeglitele. Teised harvemini kasutatavad nimed on sipelgad, auto-indeksid, simulaatorid või ussid.
0x01
Lihtsalt öeldes koguvad roomikud andmeid vastavalt oma reeglitele, analüüsivad salvestatud andmeid ja hangivad seejärel ise kasulikke andmeid.
0x02
Veebiroomiku optimeerimine jaguneb kaheks etapiks:
1: Optimeeri andmete kraapimisel;
2: Optimeerida haaramistulemuste töötlemist;
Täna räägime lihtsalt optimeerimisest kraapimisprotsessis!
0x03
Olen kokku võtnud mõned punktid optimeerimise kohta indekseerimisprotsessis:
1: Seda saab optimeerida füüsilisel aadressil, näiteks: sihtressursiserver on Tencent Cloud hosti Shanghais, püüame valida serveri samas piirkonnas, st serveri Shanghai piirkonnas, mitte valida serverit Pekingis, Qingdaos ja teistes piirkondades, vaid proovime valida serverit samast IDC arvutiruumist, me teame, et see ressursside veebileht on Tencent Cloud server, püüame panna roomaja Tencent Cloud serverile, mitte Alibaba Cloud serverile!
2: Vali stabiilne ja kiire võrk, üldiselt on roomikutel kõrged võrgukvaliteedi nõuded, püüa mitte kasutada koduvõrku, vali ettevõtte võrk või osta server andmete kogumiseks.
3: Vali efektiivsem roomiku keel, olen kuulnud, et Python on roomajates parem, aga ma pole seda kasutanud ja testin seda hiljem, täna selgitan peamiselt .net keeles.
0x04
Näiteks kiirustamise puhul on haaramiskiiruse nõuded kõrged, seda võib kirjeldada kui aja küsimust, varakult andmete hankimist, mis suurendab haaramise tõenäosust, järgnevalt kirjutasin konsooliga demo, testi selle veebisaidi andmete kogumiseks, nagu alloleval joonisel näidatud:
(Mida lühem aeg, seda kiirem)
Ülaltoodud andmete järjestus:1: Natiivselt optimeeritud kood, 2: Natiivkood, 3: Kolmanda osapoole plug-in DLL-id (paketid)
0x05
Miks võtavad kolmanda osapoole pluginad (paketid) kõige kauem aega? Kolmanda osapoole pluginad on tegelikult suur hulk natiivse koodi kapseldamisi, palju loogilisi hinnanguid ja suhteliselt mitmekülgne, mis võib viia aeglase roomamiskiiruseni.
Siin on natiivkood:
Natiivkood on vaid paar rida kõrgemal.Keskmine aeg on endiselt 184 millisekundit,Mida lihtsam kood, seda raskem on seda optimeeridaKas tunnete, kuidas saaks ülaltoodud koodi optimeerida, et saavutada keskmine aeg 99 millisekundit?Kiiruse on kahekordne!
0x06
Kui sihtressursiserver toetab gzip-i tihendamist, siis kui me veebilehele ligi pääseme ja brauser seda pärib, on päringupäisel järgmised parameetrid:
Vastuse päise parameetrid:
Sissejuhatus "Accept-Encodingu" juurde: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Encoding
Lihtsas keeles:
Klient ütleb:Toetan "gzip, deflate, sdch, br" tihendusalgoritmi, saad andmete tagastamisel kasutada mida iganes soovid.
Server ütles:Ma toetan gzip tihendusalgoritmi, seega kasutan gzip algoritmi, et andmed sulle tihendada
Klient ütleb:Olgu, siis dekrüpteerin saadud andmed gzip-algoritmiga
GZIP algoritm, mis suudab edastatud andmeid tihendada ja oluliselt vähendada edastatud sisu, seega paraneb päringute efektiivsus, seega optimeeritud kood on järgmine:
Kuigi see on väike detail, võib öelda, et efektiivsus on kahekordistunud! See on võrdne andmetega, mida kogusid kahe päevaga, ja nüüd saab seda koguda ühe päevaga ning see artikkel on pühendatud sõpradele, kes õpivad roomamist.
Märkus: gzip-i tihendusalgoritmil pole programmeerimiskeelega mingit pistmist!
Lõpuks lisa lähtekood:
Turistid, kui soovite näha selle postituse peidetud sisu, palun Vastuse
|
[Kopeeri link]
Postitatud 19.04.2018 14:21:02
|
|
|
|
Postitatud 31.12.2019 10:48:25
|
