Backoffice : premier init TRES long

[Jgoss]

J'ai un souci sur le backoffice de ma boutique en 1.7.5.1 (PHP 7.2 / Apache) : le premier chargement de la liste des commandes est TRÈS long (on est au delà de la minute parfois).

Pire, pendant que ça charge, le front est inaccessible.

Pas d'erreurs dans les logs.

J'ai activé le profiler et il ressort que c'est le "init" qui prend énormément de temps (31000ms sur mon dernier test ...). Les temps sur les requêtes SQL sont eux plutôt corrects.

Si je recharge la page des commandes, aucun souci, mon init repasse à 50ms.

J'ai pu constater que la situation s'agrave avec le temps, donc j'imagine que c'est lié à un traitement des données qui ont bien grossi depuis le lancement de la boutique (bien qu'il n'y ait que 4500 commandes)

J'ai donc 2 questions :

- Comment puis-je debugger ce qui ne va pas dans le init ?

- Comment éviter que cela bloque le front ?

Merci d'avance pour votre aide

 

Edited June 11, 2020 by Jgoss (see edit history)

[doekia]

Je soupçonne un module tier qui fait appel à un service distant.

De nombreux modules utilisent (comme des cochons) la navigation du backoffice par fainéantise de développer des taches cron correcte qui de plus font appel à des services distant.

Les modules ayant typiquement ce comportement (à bannir):
- modules transport faisant le suivi
- modules d'export produit
- modules de places de marché

[Jgoss]

Merci, c'est ce que je pense aussi.

J'ai drastiquement réduit le temps de chargement en supprimant un module de transporteur (UPS pour ne pas le nommer) qui n'était plus utilisé.

Mais ma base de données reste TRES sollicitée, notamment avec ce type de requêtes :

SELECT c.id_guest, c.ip_address, c.date_add, c.http_referer, "-" as page
                    FROM `psml_connections` c
                    INNER JOIN `psml_guest` g ON c.id_guest = g.id_guest
                    WHERE (g.id_customer IS NULL OR g.id_customer = 0)
                         AND c.id_shop IN (1)
                        AND TIME_TO_SEC(TIMEDIFF('2020-06-11 16:19:00', c.`date_add`)) < 900
                    AND c.ip_address NOT IN (1343043138)
                    ORDER BY c.date_add DESC

J'ai l'impression qu'il s'agit de logs de connexion, mais je ne vois pas où désactiver cela. Vous auriez une idée ?

 

[doekia]

Si ta base de données contient les bon index, ces requêtes ne devraient pas voir d'impact sur les performances

[Jgoss]

En fait j'ai 2 700 000 entrées dans ps_guest, et autant dans ps_connections, donc finalement, ça me semble pas plus étonnant que ça que ça rame ...

Est-ce qu'on peut nettoyer ces bases de manière sûre ? Je vois que ce plugin a l'air de faire le job, mais je voudrais pas faire de bêtises ... En tout cas, j'ai fait le test sur une instance dupliquée de ma boutique et le résultat est sans communes mesures ...

[doekia]

il y a 30 minutes, doekia a dit :

Si ta base de données contient les bon index, ces requêtes ne devraient pas voir d'impact sur les performances

 

[Jgoss]

RAS au niveau des index, j'ai fait des optimisations des tables, mais rien à faire, je ne descends pas en dessous de 50s pour la requête ci-dessus (qui n'est pas seule).

J'ai fini par purger les tables de connections, et plus aucun problème de chargement ...

DELETE FROM ps_connections WHERE date_add <  NOW() - INTERVAL 60 DAY;
DELETE FROM ps_connections_source WHERE date_add <  NOW() - INTERVAL 60 DAY;

Un peu décevant comme correctif, mais j'ai pas trouvé mieux

Merci pour le coup de main.