timing bij PHP/MySQL
ik zal even een voorbeeld geven:
een gebouw moet worden gebouwd na 12 minuten (query dus uitvoeren na 12 min). Daarnaast moet je op de pagina up to date blijven (javascript timer?)
maar de vragen zijn dus, hoe voer ik die query vertraagd uit.
enkele functies die mss werken, maar die mij niet lukte.
sleep(), usleep(), time_sleep_until()
ps. hij moet dus ook doorgaan als de gebruiker de pagina verlaat, en hij moet weer ook nog aan het door tellen zijn als de gebruiker weer terugkomt
Quote:
Nee, dat wil je niet.ps. hij moet dus ook doorgaan als de gebruiker de pagina verlaat, en hij moet weer ook nog aan het door tellen zijn als de gebruiker weer terugkomt
Het is volkomen zinloos om de database aan het werk te zetten wanneer niets of niemand iets met de resultaten doet. Wanneer iemand na een uur terug komt, kijk je gewoon hoeveel tijd er is verstreken en bereken je hoeveel vooruitgang er is geboekt.
Met de functies DATE_DIFF() en TIME_DIFF() kun je dit soort zaken gaan berekenen. Ga je er eens in verdiepen en hou in de gaten dat er geen letter php-code aan te pas komt. Hoofdstuk 12.5 van de MySQL-handleiding is je beste vriend.
Waarschuwing: Met jouw aanpak, queries uitvoeren die niet nodig zijn, loopt de boel hopeloos vast wanneer er veel spelers zijn.
EDIT: srry zal voortaan eerst lezen en dan replyen. Optie die hierboven staat is goed mogelijk, maar is meer een work-around. het probleem is dus dat er niets gebeurt als de gebruiker een week lang niets doet.
Gewijzigd op 01/01/1970 01:00:00 door David Festen
Quote:
Nee, dat is geen probleem, dat is juist de bedoeling! het probleem is dus dat er niets gebeurt als de gebruiker een week lang niets doet.
Jij moet er alleen voor zorgen dat op het moment dat de gebruiker wél iets doet, er 1 of meerdere queries worden uitgevoerd die de stand van zaken gaat bijwerken. Een gebruiker heeft bv. 53 uur niet naar zijn account omgekeken. Per uur lidmaatschap krijgt een gebruiker 2 punten toegewezen. Met TIME_DIFF() bereken je het aantal uren, 53, en dat vermeningvuldig je met het aantal punten, 2, e voilá, daar heb je het resultaat: 106.
I.p.v. 53 queries (1x per uur) heb je nu 1 query nodig. Dat scheelt nogal een slok op een borrel.
Je voert een query uit wanneer je de data nodig hebt, wanneer je niks nodig hebt, voer je dus ook niets uit.
David Festen schreef op 15.01.2007 09:24:
Dit werkt idd voor "punten" op welke manier dan ook, maar ik wil dus zegmaar een nieuw record aanmaken in tabel "gebouwen" en dat moet na een bepaalde tijd gebeuren. mss als er iemand om de gebruiker vraagt (dus de gebruiker zelf of een andere gebruiker) dat het dan moet worden gecontroleerd en geupdate/insert ? lijkt me alleen een beetje omslachtig
Het is wel de goede oplossing, het scheelt je uiteindelijk behoorlijk als je niet elk uur de data wegschrijft. Als iemand de data opvraagt, dan ga je het bijwerken, niet eerder.
Gewijzigd op 01/01/1970 01:00:00 door Martijn B
Martijn! schreef op 15.01.2007 11:02:
Het is al meerdere keren gezegd, maar dit wil je niet! Het is volkomen zinloos om een query uit te voeren wanneer niemand iets met het resultaat doet. Waarom zou je dan in hemelsnaam een query uitvoeren?Kijk eens naar de ontwikkelings versie (5.1 dacht ik) van MySQL. Hierin heb je events (zelfde principe als cronjobs(Linux) of geplande taken(Windows)). Alleen heb ik nog niet gezien dat je systeem commando's kunt uitvoeren.
Cronjobs e.d. zijn hier dus absoluut niet nodig, gebruik deze dan ook niet. Het zorgt voor onnodige belasting van jouw database. Die heeft echt wel wat beters te doen dan zinloze queries uitvoeren.
Frank schreef op 15.01.2007 12:00:
Cronjobs e.d. zijn hier dus absoluut niet nodig, gebruik deze dan ook niet. Het zorgt voor onnodige belasting van jouw database. Die heeft echt wel wat beters te doen dan zinloze queries uitvoeren.
Martijn! schreef op 15.01.2007 11:02:
Het is al meerdere keren gezegd, maar dit wil je niet! Het is volkomen zinloos om een query uit te voeren wanneer niemand iets met het resultaat doet. Waarom zou je dan in hemelsnaam een query uitvoeren?Kijk eens naar de ontwikkelings versie (5.1 dacht ik) van MySQL. Hierin heb je events (zelfde principe als cronjobs(Linux) of geplande taken(Windows)). Alleen heb ik nog niet gezien dat je systeem commando's kunt uitvoeren.
Cronjobs e.d. zijn hier dus absoluut niet nodig, gebruik deze dan ook niet. Het zorgt voor onnodige belasting van jouw database. Die heeft echt wel wat beters te doen dan zinloze queries uitvoeren.
Offtopic:
Ja koffie drinken ofzo!
hehe nee maar idd je moet dit niet doen. Gewoon query uitvoeren als de gene zich aanmeldt. scheelt veel preformance zeker bij meerdere gebruikers.
Frank schreef op 15.01.2007 12:00:
...
Wat denk je van:
- Records die moeten worden veranderd/verwijderd omdat b.v. deze langer dan een x aantal seconden in de DB staan.
- Periodieke database backups
- Proces gegevens updaten. (bijvoorbeeld hoeveel producten heb ik in mijn database of hoeveel producten zitten er in een bepaalde categorie)
- Database consistentie (Als je geen InnoDB hebt of niet van Foreign keys gebruik maakt kun je queries uitvoeren die kijken of b.v. een gekoppeld merk wel bestaat)
- Log berichten (b.v. hoeveel bestellingen vandaag)
- Een nieuwsbrief samenstellen (versturen lukt niet denk ik ;D)
Eigenlijk alle zaken in de DB die je niet door een gebruiker/bezoeker wilt laten triggeren kun je met een event afhandelen.
edit:
Je moet natuurlijk niet iets doen waar je niks aan hebt of niet mee doet. Dat ben ik natuurlijk helemaal met je eens.
Gewijzigd op 01/01/1970 01:00:00 door Martijn B
- Records die moeten worden veranderd/verwijderd
Geen cronjob nodig, 1x in de week/maand/jaar bijwerken is meestal wel voldoende. Verder kun je met de datumtijdstempels precies bepalen wat je wél en wat je niet wilt veranderen/verwijderen, dat kun je doen op het moment dat je de gegevens nodig hebt. En een database kan echt wel een paar miljard records kwijt, er staat dus niet zo snel iets in de weg.
- Periodieke database backups
Dit is inderdaad een klantje voor een cronjob, je wilt namelijk dagelijks op een vast tijdstip een backup maken.
- Proces gegevens updaten.
Lijkt mij niet nodig om daarvoor een cronjob in te zetten. Een goede query is meer dan voldoende en die voer je uit wanneer je de gegevens nodig hebt.
- Database consistentie (Als je geen InnoDB hebt of niet van Foreign keys gebruik maakt kun je queries uitvoeren die kijken of b.v. een gekoppeld merk wel bestaat)
Nee, dit heeft niks met een cronjob te maken, maar alles met een blunder van de eerste orde. Hoe verzin je het om op deze manier een 'database' aan te maken, dit heeft niks meer met een DBMS te maken. Het is ook het aller, aller zwaktste punt van MySQL en dan met name de MyISAM-engine. Het is gewoon dom om deze te gebruiken. Een lapmiddel als een cronjob om de data consistentie te checken slaat imho nergens op. Zorg voor een goede database en je hebt deze onzin niet nodig.
- Log berichten
Geen cronjob nodig, op basis van de datumtijdstempels kun je zo zien hoeveel bestellingen er op een bepaalde dag zijn verricht. Een goede query opstellen is meer dan voldoende.
- Een nieuwsbrief samenstellen
Het versturen wil je op een vast moment doen, een cronjob kan hier uitkomst bieden.
Kortom, cronjobs heb je alleen nodig wanneer je op een vast tijdstip gegevens veilig wilt stellen of wilt versturen. Het moet dus iets opleveren dat je op dat moment nodig hebt en wat je onmogelijk op een later moment kunt uitvoeren. Van de 6 voorbeelden die jij geeft, zijn er slechts 2 waarbij je een cronjob nodig hebt.
"puntent toekennen" op welke manier dan ook is het makkelijkst te doen door het verschil in tijd te meten
"Query na een bepaalde tijd uitvoeren" is het makkelijkst te realiseren door de record een datum in de toekomst toe te wijzen en het pas te laten herkennen als die datum berijkt is.
bedankt voor alle moeite
Quote:
Ik weet niet of dit wel de handigste manier is. Je kunt nu namelijk nooit meer de regels aanpassen zonder dat allerlei records moeten worden aangepast. "Query na een bepaalde tijd uitvoeren" is het makkelijkst te realiseren door de record een datum in de toekomst toe te wijzen en het pas te laten herkennen als die datum berijkt is.
Het lijkt mij handiger om in de WHERE-voorwaarde het juiste verschil in tijd op te nemen. Wil je dan de regels van het spel aanpassen, 10 minuten i.p.v. 12, dan hoef je alleen maar de INTERVAL in de query aan te passen en niet alle records die in de database staan.
Frank schreef op 15.01.2007 17:15:
Het lijkt mij handiger om in de WHERE-voorwaarde het juiste verschil in tijd op te nemen. Wil je dan de regels van het spel aanpassen, 10 minuten i.p.v. 12, dan hoef je alleen maar de INTERVAL in de query aan te passen en niet alle records die in de database staan.
Quote:
Ik weet niet of dit wel de handigste manier is. Je kunt nu namelijk nooit meer de regels aanpassen zonder dat allerlei records moeten worden aangepast. "Query na een bepaalde tijd uitvoeren" is het makkelijkst te realiseren door de record een datum in de toekomst toe te wijzen en het pas te laten herkennen als die datum berijkt is.
Het lijkt mij handiger om in de WHERE-voorwaarde het juiste verschil in tijd op te nemen. Wil je dan de regels van het spel aanpassen, 10 minuten i.p.v. 12, dan hoef je alleen maar de INTERVAL in de query aan te passen en niet alle records die in de database staan.
Je kan ook gewoon in het PHP script voortaan time() + 12 doen ipv time() + 10, dat betekent wel dat alles wat al gebeurt is niet meer terug te rekenen valt, maar dat is toch niet echt de bedoeling
Quote:
Klopt, je kunt het ook met PHP oplossen. Vaak is het alleen handiger om de database het werk te laten doen, die kan dat uitstekend zelf oplossen, daar hoef jij geen php-code voor te gaan schrijven. Scheelt je weer tijd met debuggen e.d.Je kan ook gewoon in het PHP script voortaan time() + 12 doen ipv time() + 10, dat betekent wel dat alles wat al gebeurt is niet meer terug te rekenen valt, maar dat is toch niet echt de bedoeling
Verder is het altijd handig om de code flexibel te houden, er komen namelijk altijd wijzigingen in je systeem. Spreek (helaas) uit ervaring...