1x per dag
Pagina: « vorige 1 2 3 volgende »
Kan iemand het mij uitleggen? Wat is het voordeel om te controleren of iemand de 1e bezoeker is ten opzichte van het controleren van een datum? Ik zie blijkbaar iets over het hoofd, maar ik heb geen idee wat.
Maar je zou het ook gewoon met iets van een setting veld doen ergens (ik neem aan dat je een aantal settings hebt) en daarmee kijken of het al weer 24 uur geleden is of iets dergelijks.
Tis gewoon een keuze die je maakt :)
Maar stel dat ik bij iedere pagina-aanroep zou controleren:
if ($aantal_bezoekers_met_datum_van_vandaag > 0) {
// ga cache leeggooien
}
wat is dan het voordeel ten opzichte van
if ($datum_vandaag > $datum_laatste_keer_gecachet) {
// ga cache leeggooien
}
Volgens PHP Knipper is er een bepaald voordeel van manier 1, maar ik heb geen flauw idee wat hij bedoelt??
* bump *
Ik denk dat Knipper bedoeld dat als je een tabel hebt die geupdated wordt zodra je een bezoeker op de site je daar de datum uit kan halen, dan hoef je er geen apparte tabel voor aan te maken.
Wat bedoel je precies met het "lastig vallen" van een bezoeker? Als het goed is merkt de bezoeker er toch helemaal niks van (aangezien het proces op de achtergrond wordt uitgevoerd)? De bezoeker is uitsluitend een "trigger".
"Ik denk dat Knipper bedoeld dat als je een tabel hebt die geupdated wordt zodra je een bezoeker op de site je daar de datum uit kan halen, dan hoef je er geen apparte tabel voor aan te maken."
Euh.. ik snap niet wat je bedoelt. Ik probeer nog even uit te leggen wat mijn idee was: bezoeker komt op site. Ik check (1x per sessie) of de datum gelijk is met de "laatste keer opgeschoond" datum in de database. Ja, dan niks doen. Nee, dan (op de achtergrond) opschoon actie uitvoeren en de datum "laatste keer opgeschoond" in de database wijzigen naar de huidige datum. Dat is hoe ik het bedacht had. Die manier van users in de database opslaan is me echter nog steeds niet duidelijk. Kun je een (kort) voorbeeldje geven?
Stel dat je in de database een tabel hebt waarin je site visits bijhoudt, dan zou je die kunnen gebruiken om de datum te checken. Als je zo'n tabel niet hebt, moet je natuurlijk niet één aanmaken alleen maar voor dat doel en kan je het beter doen zoals je het nu doet.
Op de achtergrond is betrekkelijk, de gebruiker ziet niet wat er gebeurd maar zou wel iets kunnen merken. Maar als het alleen cache legen is zal dat nihil zijn.
Gewijzigd op 06/12/2011 12:05:21 door Ger van Steenderen
Oké, dankjewel voor de uitleg. Ik snap wat je bedoelt met zo'n tabel (die ik niet heb overigens), maar ik snap nog steeds niet op welke manier dit sneller zou zijn. Je moet dan toch nog steeds de datums vergelijken?
Overigens heb ik een soort gelijk iets maar ik houd het bij in een logfile en check op de bestandsdatum
Hmmm, ja... maar het is maar 1 extra tabelveldje, want die kan ik vast wel bij een andere tabel stoppen met website informatie.
Ik weet dat er webshops zijn die 1x per dag (bijv. 's nachts) alle prijzen van hun artikelen bijwerken aan de hand van de actuele gegevens van de leverancier. Het kan dan gaan om honderduizenden producten. Iedere nacht draait er dan een paar uur een cronjob die alle prijzen update. Wat vinden jullie daar eigenlijk van? Is dit een goede manier? Je zou er namelijk ook voor kunnen kiezen om de prijs te updaten zodra de pagina de 1e keer op die dag wordt opgevraagd. Vervolgens sla je de prijs op in de database. Als iemand anders diezelfde dag de prijs opvraagt, dan toon je de prijs uit de database. Wat is volgens jullie beter / logischer?
* bump *
Middels crons.
@Niels... kun je een toelichting geven waarom dat via crons beter is dan te updaten op het moment dat je het nodig hebt?
Quote:
Iedere nacht draait er dan een paar uur een cronjob die alle prijzen update.
Nee, het zal op z'n hoogst 2 a 3 seconden duren om de prijzen toe te voegen dan wel te updaten, ligt er maar net aan hoe slim jij het opzet.
Kun je me nog even uitleggen waarom je dit niet via het webrpoces zou willen laten lopen? Wat is precies het nadeel daarvan?
100k records updaten kan wel in enkele minuten met slimme SQL. Helaas halen php programmeurs nogal vaak hele bakken met data cq complete tabellen over naar php om die in loopjes te processen. Overigens is de crontab het juiste mechanisme om unattended periodieke taken af te handelen en niet de sessie van de 1e gebruiker die inlogt om 00:01 uur.
Wat versta je onder unattended periodieke taken... en WAAROM niet via 1e gebruiker die inlogt? Het gaat mij vooral om het WAAROM.
Je laat een willekeurige gebruiker een proces uitvoeren waarover je niet de absolute controle hebt. Wat gebeurt er als bv de db server van de leverancier offline is, dan krijgt de gebruiker niet te zien wat hij/zij verwacht.
Daarnaast maak je een verbinding met een externe server, dat kost je min. een paar seconden, vinden gebruikers niet leuk.
@Aad, als ik met het ophalen van bakken data een aantal queries kan voorkomen, dan geniet dat mijn voorkeur.
Gewijzigd op 12/12/2011 21:52:47 door Ger van Steenderen
En wat nu als het om processen gaat waar je WEL controle over hebt? Bijvoorbeeld het vernieuwen van gecachte bestanden?