0x00
En webbcrawler (även känd som en webbspindel, webbbot, oftare kallad webbjagare inom FOAF-gemenskapen) är ett program eller skript som automatiskt skrapar information om World Wide Web enligt vissa regler. Andra mindre vanliga namn inkluderar myror, autoindex, simulatorer eller maskar.
0x01
Enkelt uttryckt samlar crawlers data enligt sina egna regler, analyserar den infångade datan och får sedan användbar data för sig själva.
0x02
Optimering av webbcrawlare kan delas in i två steg:
1: Optimera vid dataskraping;
2: Optimera bearbetningen av greppresultat;
Idag pratar vi bara om optimering i skrapaprocessen!
0x03
Jag har sammanfattat några punkter om optimeringen i crawling-processen:
1: Den kan optimeras på den fysiska adressen, till exempel: målresursservern är Tencent Clouds värd i Shanghai, vi försöker välja servern i samma region, det vill säga servern i Shanghai-regionen, vi väljer inte servern i Peking, Qingdao och andra regioner, utan försöker också välja servern i samma IDC-datorrum, vi vet att denna resurswebbplats är Tencent Clouds server, vi försöker lägga sökaren på Tencent Clouds server, inte på Alibaba Cloud-servern!
2: Välj ett stabilt och snabbt nätverk, generellt sett har sökare höga krav på nätverkskvalitet, försök att inte använda hemnätverket, välj företagets nätverk eller köp en server för att samla in data.
3: Välj ett mer effektivt crawler-språk, jag har hört att python är bättre på crawlers, men jag har inte använt det, och jag ska testa det senare, idag förklarar jag det främst på .net-språket.
0x04
För saker som rush buying är kraven för att kunna ladda ner snabbt, det kan beskrivas som en tidsfråga, tidigt att få datan, vilket ökar chansen att få den, följande är Jag skrev en demo med konsolen, testet för att hämta data från denna webbplats, som visas i figuren nedan:
(Ju kortare tid, desto snabbare går det)
Ovanstående datarankning:1: Inbyggt optimerad kod, 2: Inbyggd kod, 3: Tredjeparts plug-in dll:er (paket)
0x05
Varför tar tredjepartsplugins (paket) längst tid? Tredjepartsplug-ins består faktiskt av ett stort antal kapslingar av inhemsk kod, ett stort antal logiska bedömningar och relativt mångsidiga, vilket kan leda till långsam kryphastighet.
Här är den inbyggda koden:
Den inbyggda koden är bara några rader ovanför.Genomsnittstiden är fortfarande 184 millisekunder,Ju enklare koden är, desto svårare är det att optimeraKänner du hur ovanstående kod kan optimeras för att uppnå en genomsnittlig tid på 99 millisekunder?Hastighetsskillnaden är dubblad!
0x06
Om målresursservern stödjer gzip-komprimering, kommer begäransökningshuvudet att ha följande parametrar när vi går åt webbplatsen och webbläsaren begär webbplatsen:
Responshuvudets parametrar:
Introduktion till "Accept-Encoding": https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Encoding
På ett enkelt sätt:
Klienten säger:Jag stödjer komprimeringsalgoritmen "gzip, deflate, sdch, br", du kan använda vad du vill när du returnerar data.
Servitören sa:Jag råkar stödja gzip-komprimeringsalgoritmen, så jag kommer att använda gzip-algoritmen för att komprimera datan till dig
Klienten säger:Okej, då kommer jag att dekryptera den mottagna datan med gzip-algoritmen
gzip-algoritmen, som kan komprimera den överförda datan och kraftigt minska det överförda innehållet, så att förfrågningseffektiviteten förbättras, så den optimerade koden är följande:
Även om det är en liten detalj kan man säga att effektiviteten är fördubblad! Det motsvarar den data du samlade in på två dagar, och nu kan den samlas in på en dag, och denna artikel är tillägnad vänner som lär sig crawling.
Notera: Gzip-komprimeringsalgoritmen har inget med programmeringsspråket att göra!
Slutligen, bifoga källkoden:
Turister, om ni vill se det dolda innehållet i detta inlägg, snälla Svar
|
[Kopiera länk]
Publicerad på 2018-04-19 14:21:02
|
|
|
|
Publicerad på 2019-12-31 10:48:25
|
