[PHP/(My)SQL] voor dummies #108

@Chandler:

http://pear.php.net/package/System_Daemon/docs

Leuk, ben het aan het doornemen... child process voor php scriptjes nifty

* Unix only grrrr

Laat ook maar

[ Bericht 98% gewijzigd door xaban06 op 21-05-2013 04:07:14 ]

Hoe zorg je dat een op de achtergrond lopend proces die (bv websites scant) niet door 1 gebruiker helemaal wordt overgenomen? maar netjes de taken over alle gebruikers verdeeld?

Wat is nou de juiste manier van aanpakken? iedere actieve user qua datetime nalopen op wie het laatste en het langst geleden is gescanned? hoe doet google dat? en is daar informatie over te lezen? heb al gezocht over threads, queues etc maar kon niet echt iets vinden waar ik wijzer van werd.

Voorbeeld:

Stel ik heb 2 gebruikers die websites laten scannen.
User 1 - > website.nl
User 2 -> website.com

Nu laad ik eerst user 1 en process de eerste pagina, daaruit haal ik alle links (36)
Daarna laad ik user 2 en process de eerste pagina, daaruit haal ik alle links (15).

In het tabel staat het nu zo
id 1 -> user 1 pagina 1
id 2 -> user 2 pagina 1
id 3 t/m 39 -> user 1 vervolg pagina
id 40 t/m 55 -> user 2 vervolg pagina

Dus als ik door ga met scannen gebeurd er dit.

user 1 laad de volgende pagina's in queue (3 t/m 39) en haalt daaruit 300 pagina's
user 2 laad de volgende pagina's in queue (40 t/m 55) en haalt daaruit 500 pagina's

tabel ziet er nu zo uit (vervolg)
id 56 t/m 356 -> user 1 vervolg pagina's
id 367 t/m 867 -> user 2 vervolg pagina's

user 1 laad de volgende pagina's in queue (56 t/m 356) en haalt daaruit 3000 pagina's
user 2 laad de volgende pagina's in queue (40 t/m 55) en haalt daaruit 5000 pagina's

tabel ziet er nu zo uit (vervolg) etc
id 868 t/m 3868 -> user 1 vervolg pagina's
id 3869 t/m 8869 -> user 2 vervolg pagina's

etc etc etc

Zoals je nu ziet wordt de verhouding erg scheef tussen het inlezen en het toevoegen aan de queue, dus mijn vraag is hoe ik dit beter kan oplossen?

[ Bericht 59% gewijzigd door Chandler op 21-05-2013 19:36:51 ]

Wat is een gebruiker in deze context?

quote:

Op dinsdag 21 mei 2013 19:36 schreef Tijn het volgende:
Wat is een gebruiker in deze context?

Een gebruiker is iemand die een job invoert op de site, zie vorige bewerkte post... hopelijk een stuk duidelijker.

Ik snap echt helemaal niks van je verhaal.

quote:

Op dinsdag 21 mei 2013 19:38 schreef boem-dikkie het volgende:
Ik snap echt helemaal niks van je verhaal.

Was ik al bang voor, maar je ziet toch wel het gevolg van het invullen van de database tabellen? of moet ik het even voor je voormaken? zodat je zo'n 9000 url's in een overzicht krijgt

quote:

Op dinsdag 21 mei 2013 19:04 schreef Chandler het volgende:
Hoe zorg je dat een op de achtergrond lopend proces die (bv websites scant) niet door 1 gebruiker helemaal wordt overgenomen? maar netjes de taken over alle gebruikers verdeeld?

Wat is nou de juiste manier van aanpakken? iedere actieve user qua datetime nalopen op wie het laatste en het langst geleden is gescanned? hoe doet google dat? en is daar informatie over te lezen? heb al gezocht over threads, queues etc maar kon niet echt iets vinden waar ik wijzer van werd.

Voorbeeld:

Stel ik heb 2 gebruikers die websites laten scannen.
User 1 - > website.nl
User 2 -> website.com

Nu laad ik eerst user 1 en process de eerste pagina, daaruit haal ik alle links (36)
Daarna laad ik user 2 en process de eerste pagina, daaruit haal ik alle links (15).

In het tabel staat het nu zo
id 1 -> user 1 pagina 1
id 2 -> user 2 pagina 1
id 3 t/m 39 -> user 1 vervolg pagina
id 40 t/m 55 -> user 2 vervolg pagina

Dus als ik door ga met scannen gebeurd er dit.

user 1 laad de volgende pagina's in queue (3 t/m 39) en haalt daaruit 300 pagina's
user 2 laad de volgende pagina's in queue (40 t/m 55) en haalt daaruit 500 pagina's

tabel ziet er nu zo uit (vervolg)
id 56 t/m 356 -> user 1 vervolg pagina's
id 367 t/m 867 -> user 2 vervolg pagina's

user 1 laad de volgende pagina's in queue (56 t/m 356) en haalt daaruit 3000 pagina's
user 2 laad de volgende pagina's in queue (40 t/m 55) en haalt daaruit 5000 pagina's

tabel ziet er nu zo uit (vervolg) etc
id 868 t/m 3868 -> user 1 vervolg pagina's
id 3869 t/m 8869 -> user 2 vervolg pagina's

etc etc etc

Zoals je nu ziet wordt de verhouding erg scheef tussen het inlezen en het toevoegen aan de queue, dus mijn vraag is hoe ik dit beter kan oplossen?

Waarom doe je alles in 1 table? Da's toch niet meer bij te houden?

Waarom niet? in deze tabel staan alleen maar het volgende

id, project_id, url, ref_id, last_visit

That's all

Dus ref_id is de id met de url van de pagina waarin de url gevonden is?
Oftewel z'n 'parent'-pagina?

Misschien kun je een tabel met 'tasks' maken.
Als een thread dan klaar is met lezen, steelt hij een aantal taken van de andere user die nog bezig is. And so on.

quote:

Op dinsdag 21 mei 2013 19:53 schreef Crutch het volgende:
Dus ref_id is de id met de url van de pagina waarin de url gevonden is?
Oftewel z'n 'parent'-pagina?

Correct

quote:

Op dinsdag 21 mei 2013 19:57 schreef Crutch het volgende:
Misschien kun je een tabel met 'tasks' maken.
Als een thread dan klaar is met lezen, steelt hij een aantal taken van de andere user die nog bezig is. And so on.

Dat is dus het probleem, ik zou liever zien dat ik bv per gebruiker 1 url uitlees, daarvan de links in de database invoer en op ga naar de volgende user (job) en daarvan 1 url uitlees en etc etc etc..

Dan verdeel je geen taken, maar krijgen beide users vanaf het begin een specifiek domein en blijven altijd de onderliggende pagina's en url die aanvankelijk uit dat domein gekomen zijn scannen.

Oftewel; ik denk niet dat wat jij wil kan zonder dat de processen scheef gaan lopen, want ze nemen elkaar in principe geen werk uit handen dus is er geen balans.

quote:

Op dinsdag 21 mei 2013 20:08 schreef Crutch het volgende:
Dan verdeel je geen taken, maar krijgen beide users vanaf het begin een specifiek domein en blijven altijd de onderliggende pagina's en url die aanvankelijk uit dat domein gekomen zijn scannen.

Oftewel; ik denk niet dat wat jij wil kan zonder dat de processen scheef gaan lopen, want ze nemen elkaar in principe geen werk uit handen dus is er geen balans.

Nee klopt maar het zou mooi zijn als ik de een een url kon laten opvragen, die verwerken en dan de url van de volgende opvragen ongeacht hoe lang de queue is...

quote:

Op dinsdag 21 mei 2013 20:13 schreef Chandler het volgende:

[..]

Nee klopt maar het zou mooi zijn als ik de een een url kon laten opvragen, die verwerken en dan de url van de volgende opvragen ongeacht hoe lang de queue is...

poehhhhhh.....
Dan zou je moeten bepalen wat een url is en wat een url is komende uit zo'n 'parent'-url; eenmaal begonnen loop je het risico dat er geen eind aan het scannen komt, neem bijvoorbeeld wikipedia.

Je queue kan dan wel eens exponentieel oplopen, interessant wel, maar ook dweilen met de kraan open.

quote:

Op dinsdag 21 mei 2013 20:21 schreef Crutch het volgende:

[..]

poehhhhhh.....
Dan zou je moeten bepalen wat een url is en wat een url is komende uit zo'n 'parent'-url; eenmaal begonnen loop je het risico dat er geen eind aan het scannen komt, neem bijvoorbeeld wikipedia.

Je queue kan dan wel eens exponentieel oplopen, interessant wel, maar ook dweilen met de kraan open.

Dat bedoel ik, dus als ik het op deze manier doe moet ik OF voor iedere job een apart script laten lopen OF een script maken die jobs netjes verdeeld en ongeacht de lengte van de queue de url's verwerkt...

GlowMouse? Catch22? en anderen? jullie ideeen?

Wat perspectief is misschien ook handig. Om hoeveel websites gaat het? Hoeveel user? Hoe groot zijn de websites?

En op de vraag hier Google het doet, weet alleen Google het antwoord. Maar ga er vanuit dat hun niet 1 job per keer laten draaien.

quote:

Op woensdag 22 mei 2013 08:48 schreef Maringo het volgende:
Wat perspectief is misschien ook handig. Om hoeveel websites gaat het? Hoeveel user? Hoe groot zijn de websites?

Ok,

5 users, 5 sites en hoe groot de websites zijn maakt op zich weinig uit, de ene heeft 20 pagina's de andere 20.000.000

Een ander voorbeeld: Stel er zijn mensen die op youtube video's uploaden (LOL, wie doet dat nou?) en youtube kan maar 1 video per keer converteren!. Er is dan een wachtrij waarin video's gezet worden. Opeens is er een gebruiker die 20 video's toevoegt (speeltijd: 6000 uur) en deze komen allemaal in de wachtrij, daarna komt er 1 gebruiker en die upload een videotje van 30 seconden. Nu moet deze laatste gebruiker wachten totdat de 20 video's van de vorige gebruiker is voltooid, terwijl het eerlijker zou zijn als er van de ene gebruiker 1 video verwerkt wordt en daarna die van de ander en etc etc etc..

Duidelijker?

Maar uit de respons blijkt dat er blijkbaar niemand hier gewerkt heeft aan zo'n systeem

quote:

En op de vraag hier Google het doet, weet alleen Google het antwoord. Maar ga er vanuit dat hun niet 1 job per keer laten draaien.

Daar ga ik natuurlijk ook niet vanuit maar er zijn genoeg sites die dit soort zaken regelen met 1 job controller oid!? zie iets beter geschetst voorbeeld;


Even een grof voorbeeld; gebruiker B die dus zorgt dat andere websites ERG lang moeten wachten voordat ze klaar.


Alles is fictief maar laat zien dat 1 gebruiker dus de queue erg lang in gebruik kan nemen terwijl het eerlijker zou zijn als ik per gebruiker per ronde 1 link uitlees oid?!

Mocht iemand leesvoer hebben dan zie ik die graag gepost!

[ Bericht 19% gewijzigd door Chandler op 22-05-2013 09:38:03 ]

quote:

Op woensdag 22 mei 2013 09:10 schreef Chandler het volgende:

[..]

Ok,

5 users, 5 sites en hoe groot de websites zijn maakt op zich weinig uit, de ene heeft 20 pagina's de andere 20.000.000

Een ander voorbeeld: Stel er zijn mensen die op youtube video's uploaden (LOL, wie doet dat nou?) en youtube kan maar 1 video per keer converteren!. Er is dan een wachtrij waarin video's gezet worden. Opeens is er een gebruiker die 20 video's toevoegt (speeltijd: 6000 uur) en deze komen allemaal in de wachtrij, daarna komt er 1 gebruiker en die upload een videotje van 30 seconden. Nu moet deze laatste gebruiker wachten totdat de 20 video's van de vorige gebruiker is voltooid, terwijl het eerlijker zou zijn als er van de ene gebruiker 1 video verwerkt wordt en daarna die van de ander en etc etc etc..

Duidelijker?

Maar uit de respons blijkt dat er blijkbaar niemand hier gewerkt heeft aan zo'n systeem

Even een grof voorbeeld; gebruiker B die dus zorgt dat andere websites ERG lang moeten wachten voordat ze klaar.

[..]

Daar ga ik natuurlijk ook niet vanuit maar er zijn genoeg sites die dit soort zaken regelen met 1 job controller oid!? zie iets beter geschetst voorbeeld;
[ code verwijderd ]

Alles is fictief maar laat zien dat 1 gebruiker dus de queue erg lang in gebruik kan nemen terwijl het eerlijker zou zijn als ik per gebruiker per ronde 1 link uitlees oid?!

Mocht iemand leesvoer hebben dan zie ik die graag gepost!

Ik zou gewoon queue's maken. Je hebt verschillende q-runners die een zooi links uitlezen. Onafhankelijk vd gebruiker.

quote:

Op woensdag 22 mei 2013 09:38 schreef slacker_nl het volgende:

[..]

Ik zou gewoon queue's maken. Je hebt verschillende q-runners die een zooi links uitlezen. Onafhankelijk vd gebruiker.

Kun je dat iets breder uitleggen? q-runners? zal eens googlen!

quote:

Op woensdag 22 mei 2013 09:10 schreef Chandler het volgende:

[..]

Opeens is er een gebruiker die 20 video's toevoegt (speeltijd: 6000 uur) en deze komen allemaal in de wachtrij, daarna komt er 1 gebruiker en die upload een videotje van 30 seconden. Nu moet deze laatste gebruiker wachten totdat de 20 video's van de vorige gebruiker is voltooid, terwijl het eerlijker zou zijn als er van de ene gebruiker 1 video verwerkt wordt en daarna die van de ander en etc etc etc..

Waarom zou dat eerlijker zijn? Gewoon first in, first out lijkt me juist het toonbeeld van eerlijkheid.

quote:

Op woensdag 22 mei 2013 09:41 schreef Chandler het volgende:

[..]

Kun je dat iets breder uitleggen? q-runners? zal eens googlen!

Je hebt een queue, daarin staan je links (of verwijzingen ernaar), en je hebt een queue runner. Dan pakt je q-runner een zut links, tagged de queue (zodat andere runners niet dezelfde links gaan ophalen), processed een qitem, en sluit spul af. Voordeel is dat je meerdere queue-runners kan hebben, simultaan kan draaien, je hoeft niet te kijken naar de gebruiker, maar je pakt gewoon shit op wat in de queue staat. Is er niks, dan draait de qrunner niet (of heel kort), is er veel, dan pakt ie alles in batches op en doet ie z'n ding.

quote:

Op woensdag 22 mei 2013 09:49 schreef Tijn het volgende:
Waarom zou dat eerlijker zijn? Gewoon first in, first out lijkt me juist het toonbeeld van eerlijkheid.

Omdat iemand op zo'n manier kan zorgen dat hij 3 dagen de site voor zch aan het werk heeft en de ander daarna pas zijn job kan doen... en daarvoor wil ik dus een passende oplossing vinden..

Zat zelf te denken aan draaiende processen een time mee te geven en dan steeds een url processen van de langst wachtende oid...?

Dus eigenlijk een multidimensionale array zoals dit:


En dan nadat user 1 klaar is met de eerste website wordt ie achteraan gezet en wordt user2 de eerste volgende etc etc.

Dan worden de websites in deze volgorde verwerkt:
website1a
website2a
website3a
website1b
website3b
website1c

Dat bedoel je toch?