PHP|Débutant :: Forums

OK,
Alors la procédure donne :

Et la résultat de la requete donne :

Les distances ne sont pas identiques a ce que j'avais avant, mais comme ici tous les temps sont en secondes ça me semble normal. En tout cas les distances parcouru semblent logiques par rapport aux caractéristiques des pets!

Donc, me reste plus qu'a mettre ca en place et faire les crons pour le changement des status.

Pour stopper la course, tu penses que c'est mieux de faire comment? car faut l’arrêter a 20minutes pile (enfin si duree = 20)

En tout cas merci, ca m'a bien aider et j'ai appris plein de choses !

Et pour :

Pour le moment le id_pseudo n'est pas utile, mais apres j'espere intégrer la possibilité d'avoir plusieurs pet pour le meme joueur, donc j'en aurais peut etre besoin...

Dernière modification par ebouilleur (22-11-2011 16:13:09)

Bonjour,

Désolé je pensais avoir répondu hier soir, mais j'ai du oublier

Je ne vois pas trop comment faire pour savoir quelle est la distance a parcourir. C'est pour ca que j'avais décidé que la course serai gagné au bout de 20 minutes (car un pet niveau 1 et un autre niveau 30 ne vont pas parcourir la meme distance dans le meme temps. Surtout que pour le moment ma formule de calcule de distance est fixe, mais je dois l'améliorer pour donner un peu d'aléatoire (et aussi faire prendre en compte - je ne sais pas trop comment pr le moment - les différences entres les parcours - slalom, course de vitesse, etc)

Je suis ok sur le principe de rajouter une colonne distance, mais je la fabrique comment cette valeur "distance"?

Ouais ok... mais justement, je n'arrivais pas a fixer de distance a parcourir pour gagné, c'est pour ca que j'ai utilisé la durée... donc je ne vois pas d'autre moment que de faire un cron qui vérifie le valeur depart (table course) et quand datetime > depart + 20 min alors on passe la course au statut 3
La j'ai passé ma matiné a mettre en place tout ce qu'on a dit et a faire mon cron pour passé la course au statut 1 (presque fini)... je vais voir pour le reste, continuer de réfléchir
merci

Oui elle me plait ta proposition, tu propose encore plus ce que j'avais pensé lol (car dans mon idée je pensais favoriser certes caractéristiques en fonction des parcours - c t plus simple ^^), et/mais comme tu dis c'est bcp de boulot...
Je pense que dans un 1er temps, je vais trouver un moment d'arreter la course sans connaitre de distance, mais je garde biensur tes remarques pour le futur

Sinon, j'essaye de récupéré la plus petite valeur de puissance dans la table pet (pour déterminer puissance_min de la course) mais j'y arrive pas
Un petit coup de pouce stp?
Edit, c'est bon j'ai trouvé ca donne :

merci

Dernière modification par ebouilleur (23-11-2011 17:49:59)

Bonsoir,

Que tu te compliques la vie!

1) Déjà, il y a une imprécision au niveau des status si tu veux faire quelque chose de plus efficace, il faudrait faire ceci
0 : course ouverte au inscription
1 : cloture des inscriptions 10 min avant le départ Prêt à partir -> cron qui vérifie le nb de joueur
2 : course en cours
3 : course terminée
4: course archivée annulée
5: course archivée courrue

2) Imprécision :
- Tu gères le temps au niveau php pour ta tâche CRON c'est bien, mais ton fichier cron doit être appelé il me semble dans deux contexte différents : pour les inscriptions et pour les départs/clotures. Donc il faut que tu retrouves ces deux contextes dans ton fichier et c'est justement au niveau de ta gestion temps PHP que tu vas le vérifier.
- Ta requête ligne 37 n'est pas correcte et source d'erreur. il faudrait plutôt un truc basé sur ce critère (je te laisse le faire je vais t'en laisser un peu^^)

Et qu'elle ait la signature suivante : id_course, nb_participants. Ensuite tu pourrais aussi pour contourner les problèmes de verous monter les résultats dans une table de type memory pour pouvoir faire tes mises à jours en une seule requête.

3) Ne supprime pas les participants et sert toi du champs statuts pour archiver tes courses. Tu as donc juste un update à faire dessus. De plus ton DELETE ligne 55 n'a pas besoin d'être dans une boucle car un simple

est équivalent. L'intérêt de passer par le statut pour l'archiver est aussi que ton DELETE te générera ici une erreur dans un contexte INNODB car ta table course_participants se retrouverait avec des enregistrements orphelins...

4) Les lignes 49 à 64 sont donc inutiles

5) Les tâches à éxécuter dans ce contexte sont donc terminées : on passe le statut à 4 quand count(id_pet)<4 et on le passe à 1 sinon. Fin de la tâche cron dans le contexte inscriptions.

Voilà pour le moment.

Re,

C'est déjà beaucoup mieux, mais y a encore du taf^^
1)

tu fais cela comme tu veux mais dans ton cas je reste convaincu que c'est en effet plus simple.
2) Une table memory c'est pas compliqué, en résumé c'est comme une table normale sauf qu'elle est gérée en mémoire plutôt que sur disque dur. C'est donc très rapide selon ce que tu souhaites faire ou selon tes contraintes de requêtage.
3) Vu que l'on est dans la partie des clôtures d'inscriptions, les lignes 29 à 33 n'ont rien à faire là car la course n'est pas encore lancée, sauf s'ils nont pas le droit d'aller pisser entre temps^^.
4) Ensuite pour information, lorsque tes circuits auront un niveau, ta puissance_min pourrait faire partie des critères requis pour accéder à la course et donc intervenir en plus du nombre de participants. Par contre ici, je n'en vois pas l'intérêt car la puissance min si elle est utilisée dans ton calcul de distance, elle est recalculée dynamiquement dans ta requête de gestion de course.. Tu peux donc supprimer je pense aussi les lignes 22 à 27 (la supprimer ici te fait économiser une requête serveur x la frequence d'interrogation de la tâche par jour sur le serveur).
5) Pense toujours à optimiser un max des tâches CRON pour la raison qui vient d'être évoquée.. Ca pourrait t'éviter de mettre un jour un serveur à genoux.
6) Pour les autres requêtes je pense que tu peux passer de 3 requêtes à 2.
7) Te reste à créer la condition PHP dans ton fichier pour éxécuter ce bloc lorsque cela est nécessaire.
++

Dernière modification par Jc (23-11-2011 23:49:52)

Bonjour

Réponse: Relis bien

: Pour réduire tes requêtes.

Il te faut donc refaire ta requête initiale (plus bonne).

C'est bien mais cela n'est pas suffisant. Car ton serveur a besoin de savoir à l'execution ce qu'il doit faire : valider les courses ou lancer/cloturer les départs.

C'est pas obligatoire mais cela serait mieux^^.

++

Bonjour,

L'exemple type puisque tu me le demandes c'est par exemple pour remplacer tes lignes 4 à 16 par seulement 4 requêtes. Tu me diras ca fait plus que ce qu'il y a déjà vu que j'en ai mis que deux!
Eh bien non, si tu comptes bien, et imaginons le cas d'une course avec 50 pets, tu auras : 1+50 requêtes dans ton exemple, et le but c'est d'optimiser en priorité tes tâches CRON.
Pour être concret, imaginons les deux requêtes suivantes simples

Si tu es sous INNODB et que tu souhaites transformer ces deux requêtes en une seule telles qu'elles, tu ne pourras pas (et sous MyISAM je te rassure, encore moins!) Pourquoi? Tout simplement car sur ton select ton moteur base de données vas poser un verrou en lecture (sur ta ligne en INNODB et sur ta table en MyISAM) qui t'empêchera de mettre à jour l'enregistrement en cours de lecture, alors que les deux requêtes séparées fonctionneront. Le but, pour contourner les verrous, est de créer une table de type MEMORY et de peupler ta table mémoire avec le résultat de ton select (en deux requêtes). Ainsi tu pourras mettre à jour ta table1 mais en lisant tes enregistrement à partir de table de type memory en une seule requête.

Tu m'as tout simplement mal compris, ou j'ai du mal m'exprimer.
Ton fichier cron actuel intègre 2 parties. La première vérifie les inscriptions et la 2e valide les départ/cloture des courses.
Actuellement si tu fais une tache cron toutes les 10minutes l'ensemble de ton fichier sera executé toutes les 10 minutes. Or la première partie n'a besoin que d'être éxécutée que 3 fois par heure et la 2e partie 3 fois par heure (au lieu de 6 fois par heure pour chaque partie actuellement). Il faut donc que tu intègres dans ce même fichier un test d'execution de chaque partie selon l'heure d'execution. C'est cela que je voulais t'expliquer en te disant

Pour le reste (la 2e partie) vu que c'est la première fois que tu me la montres, il y a autant de travail à faire dessus que ce que l'on vient de faire pour la 1ere partie. Et la je n'ai pas le temps, donc je reviens vers toi ce soir je pense.

Bonne journée.

Jc

Dernière modification par Jc (25-11-2011 18:04:25)

Re,

Un exemple d'une de mes tables de production d'un client de type memory

Au niveau declaration ce qui change se situe uniquement au niveau ENGINE, rien de plus^^.

Pour ta boucle il se peut que cela vienne de ton $id_course tu ne l'as pas mis entre simple quotes comme sur les précédentes. Encore un conseil c'est de faire un $id_course = intval($var_news['id_course']); dès le départ comme ça tu peux les retirer dans toutes tes requêtes, elles n'en seront que plus performantes.

Sinon c'est qu'elle ne te retourne aucun enregistrement, en cas je la relis à tête reposée tout à l'heure.
++

Dernière modification par Jc (25-11-2011 18:07:33)

Ton go_statut3, pour ce qu'il te sert^^ autant le retirer

Je sais plus si tu peux caler par exemple ton cron toutes les 10 minutes mais décalé de 10s. Si tu ne peux définir que par minute, je te propose de le faire à 1,11,21,31,41,51 sinon tu risques d'avoir des soucis avec ta tâche. A part tout ça, ça m'a l'air bien.^^

Bonne nuit

Bonjour,

Pour répondre à ta première question ca ne change rien à "ton truc de minutes" Ca change juste pour éviter les conflits de gestion. Donc 10s voire 5s c'est bien.

Alors excuses-moi mais ta première requête, que j'ai dû lire auparavant en diagonale n'est pas bonne non plus (normalement elle devrait ne pas fonctionner correctement si tu n'as pas d'erreurs, fais-moi un retour stp dessus).
Tu as changé la logique pour la résolution de ton cron, et ce n'est pas cela.

Ce qu'il faut faire en premier lieu c'est créer ta table de type memory (1 seule suffit) et d'y remonter toutes les informations que tu as besoin pour ton traitement.

Ensuite il te faut monter les informations dont tu as besoin dedans c'est à dire toutes les courses éligibles au prochain départ. A ce propos il faudra éviter d'y mettre le filtre WHERE opq=0 sinon tu risque de ne pas avoir toutes les courses. En effet, tu as choisi d'annuler les courses qui ont au moins un pet oqp au lieu d'exclure tout simplement le pet de la course préalablement au comptage des pets dispos au départ de la course.

Il te faut faire la requête suivante

Maintenant tu as toutes les courses éligibles au départ avec l'ensemble des pets associés respectivement à chaque course (avec leur statut (course+pet)) dans ta table memory
Les données sont donc maintenant prêtes à être mises à jour.
Note1:Je vais prendre le cas de figure ou l'on exclue le pet oqp^^ ne m'en veut pas trop. Pour cela dans la définition de ta table course_participant, il faut rajouter le champ statut_pet en tinyint unsigned not null avec 1 en valeur par défaut par ex qui signinie "faisant partie de la course". On reserve la valeur 2=exclu pour la course (et tu peux virer id_pseudo il sert à rien dans cette table.
Note2: Comme au moment où j'ecris je ne me rappele pas de ta codification de statut de pet, j'utilise ici pour l'exemple 0=libre; 1=oqp, 

Alors pour le 2e update j'ai peur qu'en l'état cela ne passe pas et qu'il faille faire intervenir la table course_participant sur laquelle tu fais une jointure avec la table memory comme avec la première, et qu'ensuite que tu relies par une jointure avec la table course et pet.

L'idée est là.
Te reste encore une requête à faire pour annuler les courses qui n'ont pas au moins 4 pets au départ. Alors ca fera 5 (6 avec la suppression de la table memory à la fin) requêtes au lieu de 4, mais bon^^

++

Dernière modification par Jc (26-11-2011 17:36:31)