Project - Webscraper

[Verwijderd]

Hallo allemaal,

Ik ben nu al een enige tijd bezig met het maken van een zogeheten "Webscraper". Wat het inhoudt is dat het een aantal websites bezoekt en hiervan bepaalde informatie van ontleed. Nu ben ik er al een tijdje met dit project bezig maar loop ik tegen het feit aan dat het programma niet snel genoeg is in het aantal webrequests per sec. In het begin van het project duurde het laden en "lezen" van de webpagina ong 1 sec, nu heb ik dit weten te verbeteren naar 10 webpagina's per sec.

De volgende stappen heb ik ondernomen in het verbeteren van het programma:
> Asynchronous webrequests
> Multi threading

Maar nu loop ik tegen een aantal vragen aan:
- Heeft het nut om mijn GPU te gaan gebruiken om zo meer webcalls per sec af te vuren?
- Heb ik bijvoorbeeld het max aantal webrequests dat mijn netwerk kaart aankan al bereikt?
- Heb ik de max bereikt qua de downloadspeed welke de (doel)site mij kan leveren?

Heeft er hier iemand meer ervaring mee? Of zien jullie nog meer mogelijkheden om het aantal webrequests per minute te verhogen?

[RobIII]

Verwijderd schreef op vrijdag 20 november 2015 @ 15:42:
Maar nu loop ik tegen een aantal vragen aan:
- Heeft het nut om mijn GPU te gaan gebruiken om zo meer webcalls per sec af te vuren?
- Heb ik bijvoorbeeld het max aantal webrequests dat mijn netwerk kaart aankan al bereikt?
- Heb ik de max bereikt qua de downloadspeed welke de (doel)site mij kan leveren?

Dat zijn stuk voor stuk vragen die niet 1, 2, 3 te beantwoorden zijn en al helemaal niet als je geen informatie geeft over de beschikbare bandbreedte of gebruikte hardware bijvoorbeeld. Maar ik zal het vast voor zijn: bespaar je de moeite dat te beantwoorden want zélfs dan kunnen we nog niet heel veel zinnigs zeggen. Uiteindelijk zijn 't namelijk allemaal vragen die je zélf zult moeten beantwoorden (desnoods met ingeroepen hulp van, bijvoorbeeld, ons) op basis van metingen. Ofwel: meten == weten. Profilen is hier keyword van de dag. We weten niets van je applicatie, het platform, de hardware en niet eens de taal, niet wat "ontleden" inhoudt (is 't enkel de <title>...</title> uitlezen of ga je de hele DOM structuur in-mem opbouwen, JS runnen, CSS erbij halen en weet-ik-veel bijvoorbeeld) en ga zo maar door. Dus hier ga je zonder veel, maar dan ook véél, meer eigen onderzoek te doen en de vruchten die dat zal afwerpen met ons te delen geen één zinnige, eenduidige, hét-antwoord-op-de-vraag op krijgen.

tl;dr: Asynchroon maken, GPU inzetten, meer en/of dikkere hardware, dikkere pijpen, snellere I/O en ga zo maar door zijn allemaal zaken die je probleem potentieel(!) verlichten ja.

Verder wil ik je graag even wijzen op onze Quickstart; daarin zul je lezen dat we die 'eigen inzet' (wat heb je zélf al geprobeerd/gemeten/gezocht/gevonden...) graag al metéén in een topicstart terugzien i.p.v. dat we er om moeten vragen. Ik wil je dan ook verzoeken die quickstart in het vervolg bij 't openen van een topic te hanteren. Scheelt iedereen tijd

[ Voor 19% gewijzigd door RobIII op 20-11-2015 17:15 ]

[emnich]

Robill zegt het al prima, zoek de bottleneck en los die op. Met 10p/s zal dat zelden de hardware zijn maar ligt het aan je code. Haal die door een profiler en kijk wat het langste duurt, en focus je daar in eerste instantie op.

[Gomez12]

emnich schreef op zondag 22 november 2015 @ 08:43:
Robill zegt het al prima, zoek de bottleneck en los die op. Met 10p/s zal dat zelden de hardware zijn maar ligt het aan je code. Haal die door een profiler en kijk wat het langste duurt, en focus je daar in eerste instantie op.

Het hoeft niet perse aan je code te liggen, je hebt ook nog zoiets als een remote server. Met 10 p/s heb je een gemiddelde laadtijd per pagina van 100 ms en ik ken genoeg sites die dat niet halen.

En omdat hij het lijkt te hebben over 1 (doel)site zit ik me ook even af te vragen of die er wel op zit te wachten dat er een soort van mini-DOS op hun afgevuurd wordt. Ik heb in het verleden nog wel eens wat scrapers / spiders gemaakt alleen dan hield ik altijd aan : 1 pagina per 2 seconden per site om de doelsite niet te overladen, de snelheid haalde je dan uit gewoon genoeg sites willen scrapen zodat je hier geen last van had en je gewoon 100 tot 1000 pagina's per sec kon halen.

[emnich]

Gomez12 schreef op zondag 22 november 2015 @ 16:39:
[...]

Het hoeft niet perse aan je code te liggen, je hebt ook nog zoiets als een remote server. Met 10 p/s heb je een gemiddelde laadtijd per pagina van 100 ms en ik ken genoeg sites die dat niet halen.

En omdat hij het lijkt te hebben over 1 (doel)site zit ik me ook even af te vragen of die er wel op zit te wachten dat er een soort van mini-DOS op hun afgevuurd wordt. Ik heb in het verleden nog wel eens wat scrapers / spiders gemaakt alleen dan hield ik altijd aan : 1 pagina per 2 seconden per site om de doelsite niet te overladen, de snelheid haalde je dan uit gewoon genoeg sites willen scrapen zodat je hier geen last van had en je gewoon 100 tot 1000 pagina's per sec kon halen.

Nee, het hoeft zeker niet altijd aan de code te liggen maar je moet pas nadenken over extra hardware enzo als je code geoptimaliseerd is. Als de remote server een bottleneck is dan gaat extra hardware ook niet helpen en misschien een queue wel zodat de langzame pagina's het geheel niet afremmen.

Verder volledig met je eens dat als het om externe sites gaat je je netjes op moet stellen als bot. Over het algemeen zet ik het op 1 pagina per seconde, tenzij er iets anders in de robots.txt staat.

[McKaamos]

Verwijderd schreef op vrijdag 20 november 2015 @ 15:42:
Hallo allemaal,

Ik ben nu al een enige tijd bezig met het maken van een zogeheten "Webscraper". Wat het inhoudt is dat het een aantal websites bezoekt en hiervan bepaalde informatie van ontleed. Nu ben ik er al een tijdje met dit project bezig maar loop ik tegen het feit aan dat het programma niet snel genoeg is in het aantal webrequests per sec. In het begin van het project duurde het laden en "lezen" van de webpagina ong 1 sec, nu heb ik dit weten te verbeteren naar 10 webpagina's per sec.

De volgende stappen heb ik ondernomen in het verbeteren van het programma:
> Asynchronous webrequests
> Multi threading

Maar nu loop ik tegen een aantal vragen aan:
- Heeft het nut om mijn GPU te gaan gebruiken om zo meer webcalls per sec af te vuren?
- Heb ik bijvoorbeeld het max aantal webrequests dat mijn netwerk kaart aankan al bereikt?
- Heb ik de max bereikt qua de downloadspeed welke de (doel)site mij kan leveren?

Heeft er hier iemand meer ervaring mee? Of zien jullie nog meer mogelijkheden om het aantal webrequests per minute te verhogen?

Waar mee heb je die scraper gebouwd?
Hoe staat t met de CPU/RAM/Disk-IO/LAN-IO load van de machine waar de scraper op draait?


- GPU heeft waarschijnlijk weinig nut. Die is zeker sterk in bepaalde dingen, maar het is geen universele processor en is dus lang niet overal geschikt voor. Waar een GPU z'n kracht laat zien is in het breken van encryptie en diverse andere sterk wiskundige berekeningen (b.v. 3D modelleren, vouwen van eiwitten simuleren, e.d.)
- Wat je netwerkkaart aankan.... sja, no idea. Het OS is wel bepalend in hoeveel TCP connecties er tegelijk actief kunnen zijn. Dus die kan best ergens de knip op houden.
- De doelsite is nooit makkelijk te meten. Het kan ook prima zijn dat ze daar gewoon een cap hebben neergezet op hoeveel requests er vanaf 1 IP mogen komen. In essentie ben je ze gewoon bijna aan t DDoSsenm dus ik kan me goed voorstellen dat ze daar een beveiliging tegen hebben aangebracht.
Zijn het toevallig meerdere sites? Je kan de requests gaan verspreiden om alle sites paralel te verwerken. Misschien helpt t...


Je zou je scraper eens op meerdere fysieke lokaties kunnen zetten.
Als ze allemaal even snel klaar zijn als je huidige, dan is er waarschijnlijk gewoon een beperking aan de server kant ingesteld.
Vertragen ze allemaal, dan ben je de boel aan het plat trekken.

[ Voor 5% gewijzigd door McKaamos op 22-11-2015 18:17 ]

[Navi]

Als je bij 10 per seconde al vastloopt heeft dat niks te maken met hardware, een pentium 2 trekt dat nog, dus of de doelsite waar het vandaan komt limit jou, (of je eigen bandbreedte is te laag, maar dat betwijfel ik) of je code is superbrak.

[Verwijderd]

Mannen bedankt voor de nuttige reacties! Volgende week tentamens dus er zit momenteel wat minder progressie in. Aangezien ik zelf ook wat meer van harde getallen hou ga ik hier als eerst mee aan de slag. Ik gebruik Visual Studio 2012 als SDE en programmeer in C#. Kan er iemand mij meer vertellen over profiling binnen VS? Kan ik bijvoorbeeld zien hoeveel Cores er gebruikt worden? Hoeveel webrequests ik per seconde verstuur?

Verdere achtergrondinformatie over het project:

Projectinfo
- Binnen een domein ga ik dagelijks 400,000 pagina's af, per pagina zoek ik naar een bepaald element en lees ik de waarde uit.


Software
- Programmeertaal : C#
- Maak gebruik van AsyncWebCalls, hiermee vuur ik als het ware al wel de request af maar haal ik pas later de response op. Dit om zo onnodige wachttijd te besparen.

Hardware
- i7, 2,66 Ghz
- 180 Mbit lijn

[Gomez12]

Verwijderd schreef op maandag 23 november 2015 @ 23:49:
- Binnen een domein ga ik dagelijks 400,000 pagina's af, per pagina zoek ik naar een bepaald element en lees ik de waarde uit.

Ehm, weten zij hier ook vanaf??? Bij mij zou je gelijk in de firewall verdwijnen met dit soort aantallen dagelijks. En als je het toch zou willen dan gaan we nog wel eens praten over een feed die gewoon gemaakt kan worden met enkel dat element erin voor alle 400.000 items.
Dagelijks 400.000 pagina's afgaan voor 1 element is giga-giga-overkill van alletwee de kanten.
En persoonlijk zou ik ook nog even als het een tijdje bezig is informeren bij een advocaat hoe het ook alweer zat met databankenrecht.

Maar waarom moet hij eigenlijk sneller? 24uur * 60 minuten * 60 seconden *10 (per seconde) = 864000 pagina's die je af kan gaan in een dag, oftewel je zit net onder een halve dag.

- Programmeertaal : C#
- Maak gebruik van AsyncWebCalls, hiermee vuur ik als het ware al wel de request af maar haal ik pas later de response op. Dit om zo onnodige wachttijd te besparen.

Tja, ik betwijfel of je het met async calls wel gaat redden, ik blijf het toch een beetje zien als simple mans threads. Waarom verdeel je het zelf niet op naar threads zodat je exact weet hoeveel je er start en hoeveel je er in gebruik hebt?

[emnich]

^^dit

Zijn er geen betere manieren om die informatie te krijgen? 400k requests zou ik ook niet blij van worden en zeker niet als je dat met 10+ per seconde doet.

Als je toch op deze manier door wilt gaan en je hebt toestemming van de site eigenaar dan moet je eerst eens kijken hoeveel pagina's deze per seconde kan geven. Haal parallel eens 100 of 1.000 pagina's op en kijk hoe lang dat duurt. Er is best een kans dat de webserver niet heel veel meer kan doen.

Als je die pagina's vervolgens even lokaal opslaat en ze dan verwerkt kan je ook zien hoeveel pagina's je code per seconde aan kan, dan heb je al een redelijk beeld van waar je snelheid kan winnen.

Maar nogmaals, als het om één domein gaat dan moet je je afvragen of je wel sneller wilt.

[RobIII]

^ Los van wat hierboven al gezegd is:

Verwijderd schreef op maandag 23 november 2015 @ 23:49:
- Binnen een domein ga ik dagelijks 400,000 pagina's af, per pagina zoek ik naar een bepaald element en lees ik de waarde uit.

Er is nogal een verschil tussen 400.000 pagina's van 1Kb of 400.000 pagina's van 10MB dus wederom hebben we helemaal niets aan de gegevens die je geeft. Je zult toch écht zelf aan 't meten / profilen moeten.
Hoe je dat doet in VS is een kwestie van 3 seconden googlen en de eerste (of tweede of derde of...) link kliken. Ga dat eens lezen en als je dan komt met (zinnige!) metrieken dan kunnen we je allicht helpen meer/beter inzicht te krijgen.

[The Eagle]

Wat ik zelf zou doen is gewoon die hele pagina binnentrekken en dan lokaal analyseren.
En dat wil je niet op je eigen server doen, maar gewoon op een cloudmachine met flink wat power en opslag

[RobIII]

The Eagle schreef op dinsdag 24 november 2015 @ 19:06:
En dat wil je niet op je eigen server doen, maar gewoon op een cloudmachine met flink wat power en opslag

Dat is een mogelijke oplossing maar, quite honestly, dergelijke 'tips' zijn totaal niet relevant als a) er (nog steeds) niets zinnigs gemeld is over voorgenoemde metrieken (misschien is een oude PentiumII op 400Mhz al voldoende) en b) is het ook nog eens gevaarlijk als je bijvoorbeeld zaken gaat opslaan/analyseren in de cloud die helemaal niet buiten landsgrenzen mogen komen bijvoorbeeld en ook dat is iets wat alleen TS kan beantwoorden). Je kunt er wel een sloot (al dan niet 'cloud') "power" tegenaan gooien maar als je proces erg inefficiënt is (lees: profilen!) dan maak je geheid (veel) meer kosten dan nodig. Zo maak je me niet wijs dat al die 400.000 pagina's elke dag wijzigen; waarom zou je dan bijvoorbeeld niet gebruik maken van if-modified-since om maar eens wat te noemen. Dat scheelt je vast (ook dit is een aanname c.q. wilde gok... meten == weten!) al 375.000 pagina's analyseren/opslaan. Maar ook dan moet je wel weten of "de andere kant" dat überhaupt ondersteunt. En dat is, wederom, iets wat alleen TS kan uitzoeken/beantwoorden.

The Eagle schreef op dinsdag 24 november 2015 @ 19:06:
Wat ik zelf zou doen is gewoon die hele pagina binnentrekken en dan lokaal analyseren.

Wat zou 't alternatief zijn dan Je moet een pagina toch altijd "binnentrekken" en "lokaal analyseren"? Of je dat analyseren uitbesteedt aan een andere host of dat je 't "binnentrekken" na 50Kb afbreekt omdat je toch alleen maar geïnteresseerd bent in de <title>; ik zie even niet wat deze opmerking oplost in de zin van: hoe zie je 't voor je dat 't anders zou gebeuren?

[ Voor 39% gewijzigd door RobIII op 24-11-2015 19:21 ]

[Verwijderd]

@RoBlll Jou manier van werken spreekt mij erg aan, in de zin van meten == weten. Hier heb ik al het een en ander voor geprobeerd binnen Visual Studio. Een profiler binnen VS waar ik gebruik van maak is dat ik terug kan lezen hoelang een bepaalde methode duurt om uit te voeren qua tijd. Maar ik vind dit zelf nogal te algemeen. Informatie welke ik graag terug zou willen zien is wat specifieker:

- Hoelang duurt elke stap binnen de webcall?
- Hoeveel threads lopen er tegelijkertijd (Kan ik evt zien met behulp van Resource Manager)?
- Hoeveel cores worden er gebruikt?
- Hoeveel webcalls per seconde zijn er?

Ik heb hier snel even voor gekeken maar kon binnen VS hier geen profiler voor vinden. Daarom wil ik na mijn tentamens een GUI maken met hierin een dashboard. Hiermee wil ik de bovenstaande vragen beantwoorden. Oftewel input van jullie is zeker nog welkom! maar het project wordt over 2 weken pas weer opgepakt. Heb het heerlijke tentamen statistiek voor de boeg

[RobIII]

Verwijderd schreef op dinsdag 24 november 2015 @ 19:57:
Een profiler binnen VS waar ik gebruik van maak is dat ik terug kan lezen hoelang een bepaalde methode duurt om uit te voeren qua tijd.

Dat is geen "een profiler" maar een enkele (karige) meting. Dé profiler gaat jou alles (en meer) vertellen. Daarvoor hoef je alleen maar de linkjes die ik je gaf in de vorige post te volgen (en komt geen enkele aanpassing van je code te pas, ik neem aan dat je die tijd nu meet met een Stopwatch? Als je DateTime.Now gebruikt oid is je meting nóg kariger...)

Heb je nou een VS editie zónder profiler dan zul je even moeten googlen naar een alternatief. Er is vast iets van je gading/budget te vinden.

[ Voor 15% gewijzigd door RobIII op 24-11-2015 20:46 ]