Ik heb een webpagina met ongeveer 30 links. Al deze links wil ik openen en delen van de pagina opslaan in een database (html scrapen). Elke link een-voor-een openen gaat prima, maar ik wil kijken of ik meerdere links op de pagina tegelijk kan openen en de HTML kan scrapen. Ik maak gebruik van Ruby on Rails.
Op dit moment kan de applicatie wel meerdere processen tegelijk starten die elk van een webpagina de links 1-voor-1 scrapen.
Ik zat te denken aan twee mogelijke opties om het proces te versnellen:
1. 1 proces die alle links opslaat in de database en meerdere processen die de links uit de database haalt, opent en de HTML scraped. Deze architectuur maakt het allemaal wel wat ingewikkelder dan het nu is en ben ik niet echt een voorstander van.
2. Op de webpagina splitsen we het proces in meerdere child-processen (forken) en laten we elk child-proces een aantal links afhandelen (scrapen). Dit klinkt wat makkelijker te implementeren, maar de werkelijkheid is anders. Elk proces wil in feite zijn eigen database-connectie hebben. Dit resulteert erin dat het eerste child-proces dat klaar is ook meteen de database-connectie sluit. Hoewel het in eerste instantie wat makkelijker lijkt te implementeren dan optie 1, is het in werkelijkheid technisch veel lastiger dan optie 1. Bovendien is het een behoorlijk dure operatie, elk childproces maakt een kopie van het parentproces in het geheugen. Dit maakt het een behoorlijke dure operatie. Stel dat ik 4 childprocessen gebruik om te scrapen, dan gebruiken ze dus ook 4x zoveel geheugen.
Optie 2 is kortom technisch erg ingewikkeld en heel duur qua resources. Optie 1 is wellicht interessant om te implementeren, maar kan ik beter implementeren als de rest van de applicatie helemaal af is.
Heeft er iemand nog een goed idee hoe ik deze applicatie op een slimme manier nog kan versnellen?
Op dit moment kan de applicatie wel meerdere processen tegelijk starten die elk van een webpagina de links 1-voor-1 scrapen.
Ik zat te denken aan twee mogelijke opties om het proces te versnellen:
1. 1 proces die alle links opslaat in de database en meerdere processen die de links uit de database haalt, opent en de HTML scraped. Deze architectuur maakt het allemaal wel wat ingewikkelder dan het nu is en ben ik niet echt een voorstander van.
2. Op de webpagina splitsen we het proces in meerdere child-processen (forken) en laten we elk child-proces een aantal links afhandelen (scrapen). Dit klinkt wat makkelijker te implementeren, maar de werkelijkheid is anders. Elk proces wil in feite zijn eigen database-connectie hebben. Dit resulteert erin dat het eerste child-proces dat klaar is ook meteen de database-connectie sluit. Hoewel het in eerste instantie wat makkelijker lijkt te implementeren dan optie 1, is het in werkelijkheid technisch veel lastiger dan optie 1. Bovendien is het een behoorlijk dure operatie, elk childproces maakt een kopie van het parentproces in het geheugen. Dit maakt het een behoorlijke dure operatie. Stel dat ik 4 childprocessen gebruik om te scrapen, dan gebruiken ze dus ook 4x zoveel geheugen.
Optie 2 is kortom technisch erg ingewikkeld en heel duur qua resources. Optie 1 is wellicht interessant om te implementeren, maar kan ik beter implementeren als de rest van de applicatie helemaal af is.
Heeft er iemand nog een goed idee hoe ik deze applicatie op een slimme manier nog kan versnellen?