PHP wachtrij, hoe goed te maken

[lauwsa]

Hallo,

Ik heb in een project van mij een wachtrij geïmplementeerd, hier komen opdrachten in die later uitgevoerd gaan worden. Bijvoorbeeld:

User 1 doet een aantal handelingen en de opdracht word geschreven naar de database, deze moet morgen om 8 uur uitgevoerd worden, de volgende dag om 8 uur word het uitgevoerd als iemand op de site is, zo niet dan word het zo snel mogelijk uitgevoerd. Dan op de volgorde van wat eerst gebeurd is het eerste.

Alleen het probleem is, als er nu 2 mensen tegelijkertijd op de site komen dan word het 2 keer uitgevoerd. Ik heb niet getest als dit zo is maar dit is logisch omdat php niet sessie voor sessie afhandel als het goed is.

Ik wil er dus gaan voor zorgen dat de opdrachten maar 1 keer uitgevoerd gaan worden, dit kan je dan doen op de volgende manier.

Je schrijft naar de database als er opdrachten uitgevoerd gaan worden, hier komt dan ook een tijd bij te staan. Duurt dit langer dan 3 seconden dan word dit afgebroken op een punt waar dit mogelijk is en dan word de volgende keer de opdrachten uitgevoerd. Zo kan het script niet blijven hangen als er wat mis gaat. De pagina word pas getoond als allen opdrachten uitgevoerd zijn, duurt dit te lang dan krijgt de gebruiker een melding. (de opdrachten moeten namelijk uitgevoerd worden voordat iemand de content mag zien.)

Ik vind dit eigenlijk geen goede manier om zoiets op te lossen, of kan het niet anders dan op een methode zoals hier boven? Er zullen gemiddeld elke 5 seconden +- 10 – 500 opdrachten zijn die uitgevoerd moeten gaan worden.

Heeft iemand tips hoe dit anders te doen? Ik vraag niet als iemand mij een script wilt sturen, ik wil alleen weten als ik zo goed aan het denken ben, zo niet dan zou ik graag willen weten hoe ik dit anders kan doen.

Edit: Kleine aanpassing alinia 2

[Keiichi]

Een cronjob

[lauwsa]

Ik heb even op google gekeken, Dus ik moet een php script in cronjob zetten die alles regelt en deze elke 2 Seconden laten uitvoeren, Bedankt!

Edit:
Voor de mensen met de zelfde vraag:
http://www.cronjob.nl/cronjob-directadmin.html

Edit2:
Ik zie dat die alleen voor minuten kan. Hoe kan ik dit elke 2 seconden uit voeren? Of moet ik dan 1 script laten draaien die altijd aan blijft staan? Maar wat gebeurd er dan als de server van de host down gaat?

<< wel met een sleep(1); natuurlijk

[Voor 59% gewijzigd door lauwsa op 07-06-2011 14:03]

[MueR]

Waarom zou je een cron elke 2 seconden willen laten draaien? Je bent onderhand meer resources kwijt aan het constant aanmaken van een database connectie. Is het zo enorm vitaal dat het realtime (dus elke 2 seconden) is? Waarom is een minuut niet "realtime" genoeg?

[lauwsa]

Het gaat om een spel, hier kunnen dingne gemaakt worden, en deze moeten om een bepaalde tijd klaar zijn. Er moeten ook grondstoffen binnen komen. Dit moet zo wie zo om de 2 seconden gebeurd worden.

Edit: Dit moet dus realtime. Ik zie anders er geen oplossing voor.

[Voor 15% gewijzigd door lauwsa op 07-06-2011 14:18]

[Tead]

Waarom maak je er geen losse daemon van? Is een stuk efficienter dan elke 2 seconde een nieuw script op te roepen. Het zou mooi zijn als je dit in Perl of Python oid maakt, maar als je het echt in PHP wilt doen kan dat.

Wordt echter niet aangeraden omdat PHP niet erg goede garbage collector heeft en je dus snel memory leaks hebt.

[samo]

Is het dan niet beter om de timestamp op te slaan van het moment dat je voorwerp af is? Dan kan je logic dat verder afhandelen.

[ajakkes]

Is het niet beter om vooruit te kijken? Als tijd verstreken is, is de waarde 2 als de tijd nog niet verstreken is is de waarde 12.

[kwaakvaak_v2]

dit ruikt aan alle kanten naar een klusje voor Gearman

Beschikbaar als php extension of anders een pure php implementatie.

[lauwsa]

samo schreef op dinsdag 07 juni 2011 @ 14:26:
Is het dan niet beter om de timestamp op te slaan van het moment dat je voorwerp af is? Dan kan je logic dat verder afhandelen.

Deze word opgeslagen, maar je hebt ook dingen die voor een bepaalde tijd een X aantal items moeten toevoegen en ik heb ook dingen die elke 5 seconden voor elke speler geld. Dan krijg ik toch een hele hoop opdrachten en dan is het toch niet meer overzichtelijk?

Tead schreef op dinsdag 07 juni 2011 @ 14:25:
Waarom maak je er geen losse daemon van? Is een stuk efficienter dan elke 2 seconde een nieuw script op te roepen. Het zou mooi zijn als je dit in Perl of Python oid maakt, maar als je het echt in PHP wilt doen kan dat.

Wordt echter niet aangeraden omdat PHP niet erg goede garbage collector heeft en je dus snel memory leaks hebt.

Ik zal hier even naar kijken, ik kan alleen de basis van C++ en PHP dan. Maar kan ik dan niet de opdracht elk uur opnieuw laten starten? Dan moet wel de ene opdracht wachten tot de andere klaar is. Dan word toch alles opgeruimd.

[Zerotorescue]

lauwsa schreef op dinsdag 07 juni 2011 @ 13:45:
Alleen het probleem is, als er nu 2 mensen tegelijkertijd op de site komen dan word het 2 keer uitgevoerd. Ik heb niet getest als dit zo is maar dit is logisch omdat php niet sessie voor sessie afhandel als het goed is.

Een mogelijke oplossing hiervoor zou iets in de richting van het volgende zijn (ervan uitgaand dat je MySQL gebruikt wat wel de standaard is onder DirectAdmin):

PHP:

$dbres = mysql_query("SELECT * FROM job_queue WHERE status=0 AND time>=UNIX_TIMESTAMP()"); // status 0 = pending
while($result = mysql_fetch_assoc($dbres))
{
    // Set the status to 1 to indicate the job is being processed so other scripts skip this job
    mysql_query("UPDATE job_queue SET status=1 WHERE id=" . $result['id'] . " AND status=0 LIMIT 1");

    if(mysql_affected_rows() == 1)
    {
        // Ensure the status was set to 1 (processing) if it is still 0 (pending), due to table locking in MyISAM and row locking in InnoDB, this can never occur simultaneously

        // Proceed with job

        // Finisher
        mysql_query("UPDATE job_queue SET status=2 WHERE id=" . $result['id'] . " AND status=1 LIMIT 1"); // status 2 = finished
    }
}
// Empty the memory
mysql_free_result($dbres);

Tabel / veldnamen zijn slechts als voorbeeld, vul het in zoals je zelf wilt.

MueR schreef op dinsdag 07 juni 2011 @ 14:09:
Waarom zou je een cron elke 2 seconden willen laten draaien? Je bent onderhand meer resources kwijt aan het constant aanmaken van een database connectie. Is het zo enorm vitaal dat het realtime (dus elke 2 seconden) is? Waarom is een minuut niet "realtime" genoeg?

Met voldoende connectie caching zou dit geen probleem mogen zijn. Ik denk dat 1 database connectie per 2 seconden wel de minste resource zorgen baart bij een website zoals lauwsa heeft beschreven.

Nog een oplossing, gebasseerd op de cron job oplossing eerder aangeboden, is om een PHP script (dat iedere minuut wordt uitgevoerd) continue met 1 seconde te vertragen.

PHP:

$currentTime = time();
$stopAt = $currentTime + 60;
while($currentTime < $stopAt)
{
    // Ensure the time is accurate
    $currentTime = time();
    
    // job queue verhaal
    
    $currentTime++; // one second in the future
    @time_sleep_until($currentTime); // wait until that, unless the above already took a second or more in which case this will skip the waiting - without the @ that would generate a warning
}

[Voor 4% gewijzigd door Zerotorescue op 07-06-2011 15:14. Reden: 1e edit: Overbodige woorden weggehaald, 2e edit: foutje uit laatste lap code gehaald]

[NMe]

Je hoeft die allemaal niet realtime te doen. Die items sla je gewoon in een of andere queue op met een finish time. Als je iets met een bepaalde user wil doen (doorgaans alleen als de user zelf een pagina ververst maar is ook denkbaar in combat-situaties waar een andere speler je aanvalt) dan kijk je domweg even of je die queue moet flushen van items die al klaar zijn voordat je verder iets met die user doet. Theoretisch is het dan wel mogelijk dat twee mensen tegelijk iets met een bepaalde user willen doen en daardoor tegelijk dit script van je triggeren, maar als je je script goed indeelt door eerst te kijken of het nodig is en vervolgens meteen een update te doen die ervoor zorgt dat een andere pagina niet hetzelfde gaat doen, dan is de kans vrij klein dat je hier ooit duplicates mee aanmaakt.

[kwaakvaak_v2]

ik herhaal... kijk eens naar gearman.. Dat is er juist voor gemaakt om process queues af te handelen. Scheelt je een volledige semaphore/locking systeem in php zelf te maken.

[alex3305]

Of nog veel simpeler. De vanaf timestamp (dus 8 uur volgende dag) opslaan in een tabel. En als dan de betreffende user gequeryed wordt, kijken of die timestamp lager (dus eerder) is dan nu. Als dat waar is, dan heeft de user recht op dat item, anders niet. Items hoef je dan niet aan te maken, dan heeft namelijk een user gewoon recht op dat item... of niet .

[vistu]

alex3305 schreef op dinsdag 07 juni 2011 @ 15:28:
Of nog veel simpeler. De vanaf timestamp (dus 8 uur volgende dag) opslaan in een tabel. En als dan de betreffende user gequeryed wordt, kijken of die timestamp lager (dus eerder) is dan nu. Als dat waar is, dan heeft de user recht op dat item, anders niet. Items hoef je dan niet aan te maken, dan heeft namelijk een user gewoon recht op dat item... of niet .

Inderdaad, dat is uiteindelijk waar het om gaat. Er hoeft niets geproduceerd te worden of iets dergelijks, je flagged gewoon of het item al dan niet actief is. Hoef je niet te cronnen of wat dan ook.

[ajakkes]

Stel dat de hoeveelheid geld groeit in de tijd. Kijk je naar de tijd die verstreken is sinds te laatste update en de huidige tijd en doe je dit maal de hoeveelheid geld die in deze tijd gegenereerd word. En zet de huidige tijd in de laatste update kolom.

Voor alle grondstoffen zou je dit voor alle users tegelijk kunnen doen.

Zaken die eenmalig gebouwd worden zet je op available na timestamp. Is de huidige tijd hoger dan de timestamp is het aanwezig.

Het wordt iets lastiger als de grondstofproductie omhoog gaat na iets dat op een bepaald moment af is, maar ook daar kan je wel uit komen.

Je hoeft dan ook niet te kijken of iets al uitgevoerd is aangezien bij opnieuw uitvoeren 3 sec. later slechts grondstoffen zal uitkeren ter waarde van 3 sec.

[lauwsa]

Ik zal straks naar gearman gaan kijken,

Maar dat was idd een wakkere opmerking om iets te activeren als je er recht op hebt. Bedankt!

@ Het wordt iets lastiger als de grondstofproductie omhoog gaat na iets dat op een bepaald moment af is, maar ook daar kan je wel uit komen.

Dat heb ik al gemaakt, dus dat maakt niet uit. En van de grondstoffen gewoon:
tijd = tijd van eerste gebouw wat klaar is. - tijd laatste update
productie * tijd + grondstoffen user = grondstoffen user.

Dan is denk ik dit probleem opgelost. Bedankt :D!

[lauwsa]

Ik heb er even over na gedacht,

De methode om dingen te activeren als de tijd behaald is is niet echt mogelijk in allen omstandig heden,
Je kan namelijk andere aanvallen, dit kan je niet van te voren uitrekenen om zo maar te zeggen. Dit moet dus echt gebeuren op een bepaalde tijd en het mag maar door 1 iemand uitgevoerd worden.

Gearman,

Ziet er goed uit, maar ik ben het spel nog aan het maken en we hebben niet echt geld om zelf een server te laten draaien, we zitten namelijk bij een host. Als het spel aan het groeien is en als we er ook echt geld uit kunnen halen dan zullen we wel een server kopen. Dus deze optie lijkt me af te vallen, ik kan namelijk niet Gearman op de host zetten. (Toch? want zo ver ik zag moet je bestanden aan de server toevoegen )

De manier van NMe,

Er voor zorgen dat 2 pagina's niet het zelfde gaan doen, en alleen dingen van de user zelf of van een andere user gaan doen als hij met deze te maken heeft. Dit is te doen. Het systeem dat ik nu heb en dan een aparte tabel waar in staat als er een queue gedaan word. Dit dan linken aan een id.
Dit kan ik gemakkelijk te implementeren omdat ik het systeem van queue's oplossen gemaakt heb. Het zou idd wel beter zijn als ik dit achter de row van de queue zet.

manier van Zerotorescue,
Bovestaande maar dan op de goeie manier. (Dus via een status in de row zelf)

Manier van Tead,
Het is mogelijk, maar memory leaks heb ik liever niet.

Ik ga het denk ik dus op de manier van Zerotorescue en NMe uitvoeren, bedankt!

Edit:
Type fouten

Ik ga denk ik toch de status in de row zelf zetten, het is toch niet zo veel extra werk. (Duurt ongeveer even lang, en later heb je er meer profijt aan lijkt mij)

[Voor 10% gewijzigd door lauwsa op 07-06-2011 19:02]

[kwaakvaak_v2]

Tja.. je moet idd bestanden op de host zetten. Maar dan neem je toch een VPS oplossing, hoeft je in principe de kop ook niet te kosten. Probleem is namelijk dat je met grote zekerheid het later niet meer om gaat schrijven als het eenmaal deel van de core van je spelletje is.

En zonder zaaien, geen oogst. Dus soms moet je gewoon wat investeren om er iets uit te halen

[ameesters]

ik zou voor een daemon deze gebruiken: http://pear.php.net/package/System_Daemon
als je hoster te lui is om de pear te installeren voor je kan je hem ook lokaal downloaden en het zelf uploaden...

[ReenL]

Dit moet dus echt gebeuren op een bepaalde tijd en het mag maar door 1 iemand uitgevoerd worden.

Dat kan wel, je kunt de wachtrij in de toekomst invalidaten (praktisch waarschijnlijk verwijderen of tijd ophogen) omdat er een actie voor is gekomen.

Gearman,

Voor een duppie kan je niet op de eerste rij zitten, je hebt er inderdaad minstens een VPS voor nodig. Ik betaal hier 18 euro in de maand voor.

Manier van Tead,
Het is mogelijk, maar memory leaks heb ik liever niet.

Dit heb je uiteindelijk zelf in de hand, maar bedenk wel dat je hier commandline toegang voor nodig hebt.

[NMe]

ameesters schreef op dinsdag 07 juni 2011 @ 23:17:
ik zou voor een daemon deze gebruiken: http://pear.php.net/package/System_Daemon
als je hoster te lui is om de pear te installeren voor je kan je hem ook lokaal downloaden en het zelf uploaden...

Ik kan me heel goed voorstellen dat een hoster er niet op zit te wachten als PHP-scripts ineens als daemon draaien...

ReenL schreef op dinsdag 07 juni 2011 @ 23:27:
[...]

Voor een duppie kan je niet op de eerste rij zitten, je hebt er inderdaad minstens een VPS voor nodig. Ik betaal hier 18 euro in de maand voor.

Ik zie hier eigenlijk helemaal niks waar je per se een VPS voor nodig hebt? Een oplossing zonder cronjobs en dergelijken die gewoon binnen PHP zelf blijft draaien is prima denkbaar, en als zo'n spel groter wordt kun je altijd nog opschalen naar betere hosting. Weten wanneer je de stap moet maken naar een betere omgeving is les 1 van schaalbaarheid.

Dit heb je uiteindelijk zelf in de hand, maar bedenk wel dat je hier commandline toegang voor nodig hebt.

Dan nog zou ik daar niet voor gaan. PHP kan vanaf de shell draaien maar ik zou dat hoe dan ook niet als daemon doen. PHP is vooral leuk voor scriptjes met een begin en een einde, daarna lost je OS eventuele memory leaks wel op. Dat gaat niet lukken als het een daemon is die semi-permanent blijft draaien.

[Hielko]

Als ik dit zo lees dan is heel het draaien van cronjobs of deamons helemaal niet nodig. Het is natuurlijk moeilijk om precies een oplossing te geven als het niet helemaal duidelijk is wat het spel moet kunnen, maar zoals als uitgelegd is bijv. het aanmaken van items helemaal niet nodig. Je kan gewoon opslaan vanaf welk moment iemand recht heeft op een item. En als iemand bijv. aangevallen wordt kan je dit indien nodig updaten in de database, als hij hier geen recht meer op heeft oid.

Het moet raar lopen als een dergelijke oplossing niet mogelijk is, de spelwereld hoeft immers alleen maar te bestaan en geupdate worden als mensen actief aan het spelen zijn en pagina's opvragen, dingen versturen.

Je hebt natuurlijk inderdaad wel een probleem dat twee mensen bijv. 2x dezelfde actie proberen uit te voeren, maar dat is ook een probleem dat je potentieel houdt als je gaat werken met een deamon/cronjob oid. Als speler A bijvoorbeeld op tijd x resources+10 krijgt oid, en speler B valt hem aan waardoor hij resources-10 krijgt dan kan het net zo goed fout gaan als B de waarde van resource opvraagt, de cronjob verhoogt de waarde, en vervolgens schrijft B de oude waarde+actie weer terug. Dus over dat soort dingen zul je sowieso moeten nadenken.

[Janoz]

lauwsa schreef op dinsdag 07 juni 2011 @ 18:59:
Ik heb er even over na gedacht,

De methode om dingen te activeren als de tijd behaald is is niet echt mogelijk in allen omstandig heden,
Je kan namelijk andere aanvallen, dit kan je niet van te voren uitrekenen om zo maar te zeggen. Dit moet dus echt gebeuren op een bepaalde tijd en het mag maar door 1 iemand uitgevoerd worden.

Ik denk dat je even een knop in je hoofd om moet zetten en op een andere manier naar het probleem moet kijken. Je bent helemaal gefocust op het zo natuurgetrouw mogelijk simuleren van je spel omgeving. Dat hoeft helemaal niet. Dat een item op exact moment x klaar is en ook op dat moment aangepast wordt in de database boeit helemaal niet als op dat moment helemaal niemand kijkt. Het enige moment wanneer de state van je wereld daadwerkelijk interessant is, is op het moment dat er een actie uitgevoerd wordt. Wanneer moment Y voor moment X ligt is het ding nog niet af en als moment Y na moment X ligt is het wel af.

Uiteraard zijn er situaties te verzinnen waarbij je wel iets realtime moet doen (denk aan de wedstrijdrondes van hattrick), maar die is heel specifiek te verdedigen als zijnde een echte geschedulde actie (het is immers een globaal event dat 2x per week plaats vindt). In dit topic heb ik nog geen echte reden langs zien komen om een deamon aanpak te verdedigen, en zeker omdat je PHP gebruikt zul je die eerst moeten vinden voordat je daadwerkelijk die kant op gaat.

[lauwsa]

Ik heb het op het moment op de volgende manier uitgevoerd. Alleen items in de wachtrij behalve de grondstof per uur worden van onder na boven verwerkt. Elk dorp dat met het item waar de verwerker mee bezig is te maken heeft krijgt een grondstof update tot naar de eerst volgende update die er is. De user die op het moment actief is en als er geen dingen zijn die verwerkt moeten worden krijgt de user een volledige grondstof update.

Ja oke, daar heb je groot gelijk in, maar ik heb nu 1 row voor elk gebouw die de user heeft, word het gebouw geupgrade dan word deze row ook mee geupdate naar het gewenste level. Ik zou dit systeem lijkt me best wel erg moeten omgooien als ik het bovenstaande goed wil uitvoeren. Want als een user aan het upgrade is wil ik hem het gebouw dat hij origineel heeft laten gebruiken tot de update. En voor elk level een aparte row lijkt me niet erg handig.

[Voor 7% gewijzigd door lauwsa op 09-06-2011 07:51]

[ajakkes]

Zolang je alle data bijwerkt voor alle users op het moment dat er 1 user een pagina opvraagt loop je nooit tegen het probleem dat gebruikers iets wel of niet hebben.

Verlies niet uit het oog dat als niemand kijkt er eigenlijk niks hoeft te gebeuren. Als de server een maand stil ligt en iemand logt daarna weer in kan alles in enkele sec. bijgewerkt zijn en lijkt het alsof de tijd nooit heeft stil gestaan.

De enige reden om wel realtime bij te werken is als je de server zelf wil laten handelen richting de gebruikers of andere servers. Bijvoorbeeld als je een mailtje wil sturen naar je gebruiker dat iets af is. En dan alleen als dit niet kan wachten tot er een nieuw persoon je server bezoekt. Je kan je waardes zelfs laten bijwerken als googlebot je site bezoekt.

Je krijgt pas weer een probleem als het bijwerken van de users en hun gebouwen en grondstoffen langer gaat duren dan het geduld van je gebruikers, de browser of jou server.

Zolang je in je database netjes omgaat met het bijwerken van de data kan er weinig mis gaan. Als 2 users ongeveer tegelijk hetzelfde script oproepen mogen de acties niet 2 keer uitgevoerd worden.


Ik heb het idee dat je inmiddels wel redelijk door hebt dat je geen daemon of cronjob nodig hebt en dit prima uit kan voeren bij een simpele hosting provider. Alleen doordat ik niet helemaal zie op welke tekst je precies reageert vraag ik me af wat je huidige probleem nou precies is.

En als je genoeg gebruikers hebt heb je iedere 2 sec. een bezoeker en gebeurd alles alsnog realtime.

[lauwsa]

Mijn vraag is opgelost, heb het nu zo voor elkaar dat alles lijkt dat het realtime gebeurt maar dat dit pas geupdate word als iemand de gegevens nodig heeft. Een daemon of cronjob waren idd niet nodig.

Mijn vorige post was meer hoe ik het uitgevoerd had.

Bedankt iedereen voor jullie hulp.

edit:

De tijd dat alles uitgerekend word moet idd niet te lang duren. Maar dat komt wel goed. Zoals eerder besproken over VPS hosting, ik ga er denk ik toch in investeren. Lijkt me idd toch beter, en zo duur is dat ook weer niet.

[Voor 28% gewijzigd door lauwsa op 09-06-2011 16:07]