Suivi / résolution : lenteurs + doublons + actions enregistrées sur un autre ticket
Après analyse (slow query log + code), voici ce que j'ai trouvé et les correctifs que j'ai mis en place. Le correctif "serveur" est confirmé ; les correctifs "code" sont testés sur une instance de test, en cours de validation avant la prod. Je partage pour les utilisateurs qui ont le même souci, et pour faire remonter les points à l'équipe GestSup.
1) Lenteurs - côté serveur (le point le plus impactant)
Le buffer pool InnoDB était resté à 128 Mo pour une base d'environ 5,7 Go, d'où énormément de lectures disque. J'avais pourtant configuré 4 Go dans /etc/mysql/mariadb.conf.d/99-bufferpool.cnf, mais ça ne s'appliquait pas, même après un redémarrage de MariaDB.
La raison : le dossier /etc/mysql/mariadb.conf.d était en 774 (pas de droit d'exécution pour "autres"). Comme mariadbd tourne sous l'utilisateur "mysql" (qui n'est pas dans le groupe propriétaire), il ne pouvait pas entrer dans le dossier, et MariaDB ignorait alors silencieusement toute la config personnalisée (buffer pool, slow_query_log, innodb_log_file_size...).
Correctif :
puis redémarrage de MariaDB → buffer pool enfin à 4 Go. Gain immédiat très net sur les pages lourdes.
2) Lenteurs - côté requêtes
Trois requêtes ressortaient nettement :
- Anti-doublon à la création (core/ticket.php) : un SELECT sur date_create + title + description qui parcourt toute la table (aucune colonne indexée, description en LONGTEXT), de l'ordre de 22 s sur ~90 000 tickets.
- Vue activité / par période (dashboard.php) : jointure en virgule tincidents,tthreads,tstates + SQL_CALC_FOUND_ROWS + DISTINCT, qui examine des centaines de milliers de lignes.
- Recherche globale (core/searchengine_ticket.php) : LIKE '%...%' non indexables + sous-requêtes + SQL_CALC_FOUND_ROWS, avec des pointes jusqu'à ~160 s.
Côté code, j'ai restreint l'anti-doublon (date + titre, sans la description), remplacé SQL_CALC_FOUND_ROWS par un COUNT séparé, et remplacé la jointure qui démultiplie les lignes par un EXISTS.
Et surtout, deux index à créer en fenêtre de maintenance (avec sauvegarde) :
Code : Tout sélectionner
CREATE INDEX idx_tincidents_datecreate_title ON tincidents (date_create, title);
CREATE INDEX idx_tincidents_disable_datecreate ON tincidents (disable, date_create);
Le premier fait passer l'anti-doublon de ~22 s à quelques millisecondes.
3) Doublons de tickets / actions en double
La vérification anti-doublon n'est pas atomique et il n'y a pas de contrainte d'unicité : pendant les ~22 s de la requête la page semble figée, l'utilisateur reclique, et on se retrouve avec 2 tickets (ou 2 commentaires / 2 changements d'état). Il n'y a pas non plus de garde anti-re-soumission côté serveur, ni de désactivation du bouton côté navigateur.
De mon côté, j'ai ajouté deux protections contre les doublons :
- côté navigateur : le bouton "Enregistrer" se grise dès le clic, pour empêcher un deuxième envoi (double-clic).
- côté serveur : si la même action arrive deux fois de suite (double-clic, rafraîchissement de page, renvoi réseau), la deuxième est reconnue comme un doublon et n'est pas enregistrée.
Ainsi, même si la demande part deux fois, un seul ticket (ou un seul commentaire) est créé.
4) Action enregistrée sur un AUTRE ticket
C'est le point le plus gênant. À la création d'un ticket, l'identifiant utilisé pour la redirection, l'upload des pièces jointes et les actions est l'identifiant PRÉDIT (le prochain auto-increment), et non l'identifiant réel renvoyé par lastInsertId(). Si deux techniciens (ou deux onglets) créent un ticket quasiment en même temps, ils reçoivent le même identifiant prédit, et les actions/pièces jointes de l'un peuvent atterrir sur le ticket de l'autre.
Correctif : après l'INSERT, on se base sur le vrai lastInsertId() pour toute la suite du traitement.
Au final, le redémarrage de MariaDB avec le bon buffer pool a déjà beaucoup soulagé les lenteurs. Les correctifs côté code traitent les doublons et les actions sur le mauvais ticket.
Merci pour le travail réalisé sur GestSup !
