"Tâches planifiées" en php - Page 1

Mon titre est certainement techniquement incorrect, mais je ne voyais pas comment dire ça autrement.

J'aimerais avoir, en PHP/SQL, des actions qui se produisent de manière répétée après un certain laps de temps.

Par exemple:

- Pour un forum: chaque jour, effacer les sujets plus vieux de 31 jours
- Pour un jeu PHP: chaque jour, redonner tous les points de vie de tous les joueurs

Je pense que ces exemples sont assez parlants, je n'en mettrais donc pas d'autre, vous devez avoir saisi l'idée

Donc comment je fais ça ? Y'a t-il un espèce de cron pour SQL ? Ou alors j'ai une fonction maintenance par exemple, appellée à chaque fois qu'une page est générée, qui prend en entrée un timestamp, si la différence avec le timestamp actuel est de 24h (pour l'exemple 2) alors j'effectue toutes mes tâches, je renvoie un timestamp que je stocke à la place de l'ancien etc. et je répète ? Ou alors je gère ça au cas par cas ? (pour l'exemple 1, càd que avant d'afficher les sujets, je regarde ceux qui doivent être lestés).

Dans tous les cas ça me parait assez lourd pour le serveur, donc je ne vois pas trop comment faire de manière efficace...

Merci d'avance pour votre aide

Que je sache, ça n'existe pas... tu as donc deux solutions : soit un script PHP exécuté par un cron sur ton serveur si tu as le droit de travailler avec, soit outil qui, lors de la première connexion du premier utilisateur et ce chaque jour commence par exécuter la tâche quotidienne, puis marque qu'elle l'a fait pour le jour en question (voire qu'elle a aussi rattrapé les jours où personne ne s'est connecté). Ce n'est pas très propre et ça fonctionne uniquement pour des tâches liées exclusivement et directement au forum (par exemple : ça ne peut pas envoyer de façon sûre un e-mail tous les jours à une date donnée ni effectuer une sauvegarde strictement quotidienne).

Au besoin, certains sites comme l'excellent webcron te proposent gratuitement de créer des tâches "cronées" (par contre c'est moins configurable que le vrai cron, et tu ne peux pas répéter une tâche plus souvent qu'une fois par heure, mais c'est déjà pas mal).

Ok, merci Nil, je pensais aller dans ce sens là. Faut tester à chaque utilisateur connecté si c'est le premier de la journée, mais bon faute de mieux...


Zephyr, ça serait mieux mais si jamais leur site est down ou quoi, plus de maintenance donc bof...

Si jamais mes sites utilisant cette méthode viennent à avoir un serveur dédié je passerais par cron, mais pour le moment je vais faire comme dit.

Merci .

bon aussi, chaque fois qu'un topic est posté tu peux faire un delete from topic where <trop vieux>

squalyl (./5) :
bon aussi, chaque fois qu'un topic est posté tu peux faire un delete from topic where <trop vieux>

oui voilà, tant qu'il n'y a pas de visiteur, ça ne sert à rien de changer l'état du site...

voué, faut voir la nature des procédures de maintenance aussi : si ça balance des requêtes assez lourdes et qu'il y en a pour 20 secondes c'est pas une super idée de les déclencher quand il y a des visiteurs (d'une part parceque ça charge le serveur au mauvais moment, d'une autre parceque le mec va attendre 20 secondes que sa page s'affiche du coup)

par contre ça a le mérite d'être facile à mettre en place... c'est juste qu'à mon avis pour tout un tas de raisons (entre autres celles ci-dessus, et le fait que conceptuellement c'est assez moyen de mélanger accès utilisateur et maintenance), c'est à réserver exclusivement à des petits sites

C'est sûr, mais ça tombe bien parce que souvent petit site = hébergeur pourri = pas de cron, et gros site = serveur dédié = cron.

Encore une fois, la nature de l'informatique est bien faite

pas forcément, y'a des petits hébergeurs mutualisés (peu, certes) qui proposent un cron, comme hostgator par exemple (merci nEUrOO)

Zephyr (./7) :
(d'une part parceque ça charge le serveur au mauvais moment, d'une autre parceque le mec va attendre 20 secondes que sa page s'affiche du coup)

Tu peux ne pas lancer la requête si y a trop de monde, et tu peux la lancer seulement une fois que tout est envoyé à l'utilisateur plutôt qu'avant (voire même faire une requête ajax séparée pour éviter que l'icône de chargement reste longtemps...)

mwé, dans le 1er cas ça rend la procédure encore plus hasardeuse, dans le deuxième le mec verra quand même la page se charger pendant un temps anormalement plus long que d'habitude (même si elle s'affiche rapidement), et dans le 3eme c'est le même problème que pour le 1er avec une cause différente

Il existe aussi http://www.crontab.fr/ avec une interface un peu austère mais qui a toujours bien marché pour moi.
Si tu as peur que le site que tu utilises soit en rade, tu peux toujours en utiliser plusieurs pour avoir de la redondance

Zephyr (./11) :
mwé, dans le 1er cas ça rend la procédure encore plus hasardeuse, dans le deuxième le mec verra quand même la page se charger pendant un temps anormalement plus long que d'habitude (même si elle s'affiche rapidement), et dans le 3eme c'est le même problème que pour le 1er avec une cause différente

Ben c'est pas hasardeux, si c'est juste pour faire du ménage ça pose pas de problème même si les 3/4 des clients avaient le js désactivé...

ça dépend vachement de l'application. perso si je veux que mon ménage supprime tous les messages sauf les 20 derniers, ça peut me poser problème si 3/4 des utilisateurs qui arrivent peuvent voir 25 messages juste parcequ'ils n'ont pas de quoi déclencher une procédure serveur de maintenance.

(et de façon plus générale, ça me semble curieux de faire dépendre une procédure uniquement serveur de la visite et de la configuration d'un client)

- alors c'est pas juste du ménage si il *faut* supprimer tous les messages sauf les 20 derniers... pour moi ménage = un truc qui améliore l'efficacité, mais le moment exact importe peu (i.e. dans ton exemple ce serait supprimer des messages qui sont déjà invisibles pour l'utilisateur)
- c'est "curieux" mais c'est un workaround correct si on a pas le choix

- ok, on a pas la même définition alors ^^ (j'ai plein de cron de "ménage" partout, mais pour beaucoup ça deviendrait gênant si il y avait un gros retard dans leur exécution)
- justement c'est le point que je soulignais : ici il y a le choix, et pour moi il est préférable d'utiliser webcron ou crontab.fr (ou les deux, comme proposait Microbug, même si je doute que ces deux outils soient moins sûrs qu'un "petit site" qui n'a pas son propre cron)

Mais en contrepartie c'est plus simple à configurer si tout est contenu dans le code et qu'il n'y a aucun serveur externe à prévenir d'un éventuel changement ^^

vi, c'est vrai que ça te libère d'une lourde tâche

surtout que comme ça marche avec des URL il y a quand même pas mal de possibilité que ça suive le changement ^^