Contexte :
Après plusieurs années en GestSup 3.2.18 sur une plate‑forme vieillissante, nous avons migré directement vers GestSup 3.2.58 et mis à jour tout l’environnement : Debian 12, Apache 2.4.65, PHP 8.4.14 et MariaDB 10.11.14.
Avant nous étions sur Serveur : Windows 10 | GestSup : 3.2.1 | WAMP : 3.2.2 | Apache : 2.4.46 | PHP : 7.4.9 | MySQL : 5.7.14
La procédure officielle a été suivie (sauvegarde, extraction du zip, suppression du dossier install, mise à jour de la base) et le memory_limit a été porté à 512 MB.
L’outil d’administration ne signale aucun avertissement majeur.
Environnement
Notre instance gère aujourd’hui plus de 84 000 tickets pour 5 techniciens travaillant en même temps sur la base.
Le serveur dispose de 7,8 Go de RAM, la base de données pèse moins de 200 Mo et tous les modules PHP requis (imap, curl, mbstring, etc.) sont installés.
Problème
Depuis la migration, la création ou la modification de tickets est anormalement lente :
- la page reste bloquée plusieurs secondes/minutes et affiche parfois le message « Ticket déjà créé », ou peu créer un doublon de ticket
- certaines actions (commentaires, changements d’état) sont enregistrées en double.
En parcourant le forum, nous avons relevé plusieurs pistes :
- des lenteurs causées par l’envoi automatique de mails = Nous n'utilisons pas cette fonctionnalité
- un gel lié au paramètre MariaDB innodb_buffer_pool_size = correctement dimensionné
- des doublons provoqués par des clics répétés = un seul clic suffit à provoquer le problème.
Existe‑t‑il un bug connu en 3.2.58 ou une optimisation (Apache/PHP, index SQL, options GestSup) recommandée pour des bases volumineuses ?
Comment corriger le problème ?
Merci d’avance pour vos retours
