Bonjour,
 
Voilà, j'ai une appli web en PHP/Mysql qui permet de gérer des inscriptions à la cantine sur le mois et pour un ensemble de personnes. J'ai donc fait une page web qui affiche les jours du mois en colonne et les personnes en ligne, une personne par ligne. A chaque intersection, on trouve une case à cocher : si elle est cochée, la personne correspondant à la ligne est inscrite à la cantine pour le jour correspondant à la colonne.
 
Mine de rien, ça représente pas mal de cases à traiter au final (environ 100 personnes et en moyenne 20j ouvrés par mois). Sur ma station de test, ça prend un peu de temps (40s) pour traiter le formulaire et réafficher le planning. Mais en prod, c'est un serveur mutualisé et là, ben j'ai des pbs. Apparemment pas de timeout (on n'a pas de msg qui s'affiche en ce sens) mais le script s'arrête à un moment donné et réaffiche pas tout le planning ou n'a pas pris en compte en BD tous les changements. C'est pas systématique mais aléatoire.
 
En BD, un enregistrement à la cantine, c'est un ID d'enregistrement, la date du jour du repas, l'ID de la personne + 2-3 autres infos.
 
Auriez-vous une solution à me proposer qui ne m'obligerait pas à changer la structure de la table ou d'hébergeur ?
 
Merci par avance

Ya du JS / JQuery ou c'est du pur PHP ?
 
Qu'est-ce qui laggue, le PHP ou le JS ?
 
Quel est le poids du document généré ?

Très peu de JS, surtout du php et un formulaire html relativement conséquent puisque 100 personnes * 20j = 2000 cases à cocher environ
Le temps d'affichage du planning est entre 9s et 11s sur le serveur mutualisé.
La page html fait environ 264 ko. Le POST fait environ 122 ko et met environ 21s à être traité. En effet, en BD je ne stocke que les inscriptions des personnes pour les jours. Comme quand on poste un formulaire à base de cases à cocher, seules les cases cochées sont envoyées, j'ai mis un champ caché de type array qui contient tous les jours/personnes avec la forme suivante : date#IDpersonne#IDInscription
 
En fait, je ne traite pas directement les cases à cocher mais ce champ caché (via une boucle). Je fais un explode('#', $ValeurCouranteChampCache);
Si IDInscription == 0, ça veut dire que la personne "IDpersonne" n'est pas inscrite à la cantine pour le jour "date". Dans ce cas, je vérifie s'il était inscrit avant que le formulaire soit posté. Pour ça, je vérifie dans les cases à cocher si l'un d'elle pour le jour et la personne à une valeur "date#IDpersonne#IDInscription" dont IDInscription > 0. Si oui, je supprimer l'entrée IDInscription.
 
Si IDInscription (celui du champ caché) > 0, alors je crée une entrée dans la BD pour inscrire "IDpersonne" pour le jour "date".
 
Donc quoi qu'il arrive, je fais environ 2000 tours de boucle.

Il faut mesurer ce qui prend le plus de temps :
- si c'est du traitement brut PHP : optimiser les algorithmes, utiliser du "cache" pour les résultats intermédiaire etc.
- si c'est des entrées-sorties comme les accès à la base de données.
  - nombre de requêtes à la base de données : voir s'il n'est pas possible des les regrouper
  - temps moyen d'une requête excessif : optimiser la requête, les index etc.
 
Edit : pour mesurer le temps microtime/time sont tes amis. $mtime = microtime(true); usleep(123456789); echo (microtime(true) - $mtime). ' microsecondes écoulées';

Ben c'est le traitement du formulaire qui prend du temps + accès à la BD puisque dans un certain nb de cas, je dois vérifier si la personne est inscrite. Si elle ne le doit plus, supprimer l'entrée. Au contraire, si elle doit l'être, créer l'entrée dans la BD.
Ca nous en fait des requêtes.  
 
Je peux peut-être récupérer toutes les inscriptions du mois d'un personne, comme ça, pas besoin de faire de vérif en BD de l'existence d'une inscription. Pour les suppressions, je peux les mettre dans un tableau et faire toutes les suppressions d'un coup.
 
Ca fera peut-être gagner un peu de temps...

Bonjour,
Etes-vous sûr de l'optimisation du code? Pas de boucles qui viendraient freiner les performances?

Tu peut pas inscrire une personne même si elle est déjà inscrite ?

La question, c'est :
 
Où le temps est-il le plus dépensé ?
 
En MySQL ou en PHP ?
 
cf le post de czh, il faut logguer le temps de toutes les requetes MySQL et le comparer au temps total de la page en affichant le porcentage que ca représente.
 
Comme ça tu sauras exactement où concentrer tes optimisations.
 
C'est un premier step obligatoire si tu veux être efficace.

Ce qui prend le plus de temps, c'est la boucle sur environ 2000 entrées du formulaire. Parce que pris individuellement, une entrée du formulaire est traitée très rapidement.
 
J'ai finalement trouvé une solution : je propose le planning avec 2 types de vue, le mois et la semaine (le nb de semaines à afficher étant géré ans le fichier de conf, par ex, 2 semaines). Comme ça, en consultation, l'utilisateur peut voir tout le mois. En cas de besoin de MAJ du planning, il passe en type de vue "semaine", ce qui réduit à environ 50% la taille du formulaire. J'ai pas encore testé, mais là, devrai plus y avoir de pb.
 
Autre avantage : la fonction qui affiche désormais le planning ne prend plus en entrée le mois et l'année mais une date de début et de fin. Je peux donc même au besoin ne plus qu'afficher le planning que d'1 seul jour si vraiment j'avais encore des pbs.

C'est bon, j'ai mis en prod, ça résout apparemment le pb d'avoir un formulaire plus petit à traiter