[Résolu] Une requête d'update de la table wp_options impact les performances
Il s'agit du forum d'assistance technique de WPML, le plug-in multilingue pour WordPress.
Il est accessible à tous, toutefois seuls les clients de WPML peuvent y publier leurs messages. L'équipe du WPML répond sur le forum 6 jours par semaine, 22 heures par jour.
Hier en faisant un profiling des performances d'un site, j'ai remarqué qu'en désactivant tous les plugins au-delà des essentiels pour le site (WPML, WooCommerce et WP Grid Builder pour les filtres produits) j'avais toujours des ralentissements (temps de réponse du serveur assez lent) à l'ouverture des pages, même les plus simples.
Dans cette situation, le site devrait être très rapide, j'ai donc utilisé Code Profiler Pro pour voir quel code ou éventuelles requêtes posaient un problème. Et, j'ai remarqué qu'à chaque ouverture d'une page, votre plugin lançait une requête de ce type :
UPDATE `wp_options` SET `option_value` = 'a:2:{s:18:\"WPML_User_Language\";a:1:{s:35:\"WPML_User_Languagehow_to_set_notice\";O:11:\"WPML_Notice\":24:{s:30:\"\0WPML_Notice\0display_callbacks\";a:0:{}s:15:\"\0WPML_Notice\0id\";s:35:\"WPML_User_Languagehow_to_set_notice\";s:17:\"\0WPML_Notice\0text\";s:348:\" <h2>Do you want the WordPress admin to be in a different language?</h2>\n <p>\n WPML lets each user choose the admin language, unrelated of the language in which visitors will see the fron [...]
Après recherche sur votre forum, j'ai découvert que les erreurs liées à la table d'option étaient fréquentes et j'ai supprimé cette ligne de ma base de données. J'ai également supprimé la ligne icl_admin_messages.
Cette action seule semble avoir amélioré les performances assez nettement. Mais désormais en faisant un profiling, je vois que la table est toujours mise à jour à chaque ouverture d'une page et j'ai peur que cela continue de causer des lenteurs.
Avec Code profiler, cela reste souvent la requête la plus lente, lorsque tous les autres plugins sont désactivés.
Existe-t-il un moyen de désactiver cette notice ? D'autant que celle-ci parait proposer d'afficher l'admin dans une autre langue, ce qui ne me sert à rien, et n'a en plus encore moins de raison de s'exécuter sur le site lorsqu'un visiteur non authentifié visite les pages.
Merci d'avance pour votre aide.
(Nicolas, vous devez déjà avoir accès à ce site de dev à cause d'un autre ticket, si cela peut vous aider à analyser le problème)
Merci d'avoir pris le temps de déboguer ce problème vous-même,
Avez-vous essayé de supprimer toutes les entrées wpml_notices de la table wp_options ?
Veuillez suivre les étapes suivantes :
- Créez une sauvegarde complète du site
- Connectez-vous à la base de données
- Accédez à la table wp_options
- Recherchez et supprimez l'entrée portant le nom wpml_notices.
- Vérifiez à nouveau si le problème a disparu.
Veuillez me dire si vous avez procédé comme indiqué ci-dessus. Si les notifications réapparaissent même après avoir effectué cette opération. Je vous recommande également d'aller sur WPML > Assistance Technique > dépannage > lien caché
Notez qu'il est normal que ces notifications réapparaissent, car elles sont là pour avertir votre système qu'il y a des changements à effectuer.
Merci pour votre réponse.
J'ai fait les 2 opérations, suppression dans la base (j'avais déjà fait ça, mais l'enregistrement reivent sans cesse) et suppression par l'assistant technique.
Cependant quand j'exécute un test de performance, j'ai encore la table wp_option qui est mise à jour à chaque accès. Cette fois la requête est un peu différente :
UPDATE `wp_options` SET `option_value` = 'a:2:{s:26:\"taxonomy-term-help-notices\";a:2:{s:10:\"pa_alliage\";O:11:\"WPML_Notice\":24:{s:30:\"\0WPML_Notice\0display_callbacks\";a:1:{i:0;a:2:{i:0;O:37:\"WPML_Taxonomy_Translation_Help_Notice\":2:{s:57:\"\0WPML_Taxonomy_Translation_Help_Notice\0wpml_admin_notices\";O:12:\"WPML_Notices\":6:{s:27:\"\0WPML_Notices\0notice_render\";O:18:\"WPML_Notice_Render\":3:{s:38:\"\0WPML_Notice_Render\0dismiss_html_added\";b:0;s:35:\"\0WPML_Notice_Render\0hide_html
Cette requête prend 1.8sec ce qui est vraiment problématique, je ne comprends pas pourquoi exécuter des requêtes de mise à jour sur la base quand des personnes accèdent au site sans être connecté.
Faut-il que je désactive WP Cron (qui exécute des tâches d'arrière-plan lors d'accès utilisateur) pour éviter ce problème ? Je n'ai pas de problème à ce que votre plugin enregistre les notices dans la base sur le principe, mais j'ai réellement l'impression (et après suppression de l'enregistrement la première fois, cela s'est révélé vrai) que cela impacte les performances.
J'ai accédé à votre site et je n'arrive pas à retrouver aucune « Notification » visible sur le dashboard.
Est-ce que les requêtes sont toujours en cours d'exécution dans le backend ? S'agit-il de la même requête avec le même contenu de notice ?
Quel est le nombre de lignes exécutées ? Parce que je ne trouve pas logique que ce type de requête ajoute 1.8s à la vitesse de chargement, pourriez-vous partager le profilling complet de votre performance avec les requêtes les plus lentes de WPML ?
Et puis-je installer le plugin Query Monitor sur votre site de développement et inspecter les requêtes moi-même ?
Non, il n'y a effectivement aucune notification visible, je trouve donc d'autant plus étrange qu'il y ait des updates incessantes. La requête dont je parle dans mon dernier message ne semble pas être la même que celle relevée dans mon premier message, comme vous pouvez le voir dans le code que j'ai donné.
Comme il s'agit d'une requête d'update, cela ne parait créer qu'une seule ligne. Pour les 1.8 sec, je suis bien d'accord avec vous, mais vous pourrez constater le chiffre vous-même, voici le détail du profiling de la DB pour ce test sur lequel vous pourrez voir le résultat :
lien caché
Query Monitor est déjà installé, mais non activé sur le site, je l'ai réactivé pour que vous puissiez jeter un œil. Je n'ai pas la requête complète que WPML fait, ce qui veut dire que je ne peux pas connaître sa complexité, mais j'ai des milliers d'articles sur le site, une cinquantaine d'attributs de produits et des centaines de valeurs d'attributs, donc si WPML fait une requête en JOIN avec d'autres tables peut-être que c'est la cause de ces ralentissements ?
Après vérification, j'ai constaté que ces requêtes n'affectaient pas vraiment la vitesse de chargement du site et voici ce que j'ai fait :
1- Utilisation de Code Profiler
Dans WPML, nous ne sommes pas familiers avec cet outil mais je l'ai essayé et j'ai fait ce qui suit :
- J'ai sélectionné 3 pages différentes et j'ai lancé le profiler, les requêtes les plus importantes n'étaient pas celles de WPML notices : lien caché lien caché lien caché
Cependant, j'ai remarqué que le nombre de requêtes était de plus en plus élevé, j'ai donc décidé d'essayer plusieurs fois le même profilage pour la même page. J'ai utilisé cette page comme exemple : lien caché
Et, voici le résultat le plus élevé que j'ai obtenu : lien caché
2- Query Monitor et Load timings plugin
J'ai décidé d'utiliser QM pour voir plus de détails sur cette requête, mais je ne l'ai pas trouvé, il n'y a pas de "Update `wp_options` "pour les notices WPML" : lien caché
Et la vitesse de chargement est d'environ 4s en utilisant Page load time chrome extension
et la requête la plus lente est celle-ci : lien caché
Conclusion : nous ne savons pas exactement pourquoi le code profiler détecte ces requêtes et pas QM. Mais la vitesse de chargement semble bonne, je pense qu'il est évident que WPML est vraiment optimisé et qu'aucune requête lente n'est enregistrée lorsque l'on navigue directement sur votre site.
J'apprécie votre compréhension et j'espère que les choses sont plus claires.
Merci pour votre enquête !
Je comprends que ce comportement vous semble étrange, surtout que QM ne ressort pas les mêmes infos que Code Profiler. Mais je peux vous garantir qu'en effaçant wpml_notice (il n'y avait qu'un enregistrement) de ma base de donnée, les performances étaient bien meilleures (lors de ma découverte de cette requête).
Les filtres que j'utilise, générés par WP Grid Builder, s'affiche après 1.5s maximum, alors qu'avant la suppression, il fallait jusqu'à 6 secondes.
Je ne garanti pas que ça soit uniquement lié à WPML, je l'utilise sur de nombreux autres sites et je n'ai jamais eu de problème de ce genre. Mais est-ce qu'il serait possible de limiter la fréquence d'exécution de cette requête ?
Je me demande si cette requête n'est pas exécutée par WP CRON, comme je l'ai déjà évoqué. Comme Code Profiler s'exécute à la manière d'une navigation privée, par défaut sans utilisateur authentifié, est-ce que WP-CRON n'est pas immédiatement exécuté (car il s'exécute ponctuellement lors d'accès au site par les visiteurs) ce qui exécute ce type de tâches en arrière-plan et rajoute des lenteurs au profiling ?
Que le profiling soit lent, je m'en fiche si l'expérience utilisateur est bonne, mais j'ai envie d'éviter que des nouveaux visiteurs soient impactés dans leurs performances à cause de l'exécution de WP-CRON.
Est-ce que ça vous semble une théorie valide ? Je pourrais tenter de désactiver WP-CRON et de l'exécuter par une tâche planifiée.
Nous ne pourrons pas les limiter, mais vous pouvez les désactiver si vous le souhaitez.
Allez à \WPML_User_Language::add_how_to_set_notice dans
wp-content\plugins\sitepress-multilingual-cms\classes\user-language\class-wpml-user-language.php
et juste retourner après la première ligne de la méthode, ou commenter l'appel à la méthode au-dessus de cela
Même chose dans \WPML_Taxonomy_Translation_Help_Notice::add_term_help_notice_to_admin_notices Dans wp-content\plugins\sitepress-multilingual-cms\classes\taxonomy-term-translation\class-wpml-taxonomy-translation-help-notice.php
Merci pour ces précisions, je sais donc que ça n'est pas lié à WP-CRON mais pas encore pourquoi ça s'exécute de manière systématique. Quant à changer le code du plugin, je préfère éviter de toute manière, ce code sera écrasé à la prochaine update, nous sommes bien d'accord ? Il n'y a pas possibilité de désactiver ça depuis le thème enfant ? (en faisant un remove_filter ou remove_action)
Je ne suis pas sûr pourquoi le profileur l'exécute, ces notifications ne devraient pas s'exécuter de façon récurrente, car elles ne s'exécutent que lorsque WPML veut notifier l'utilisateur sur le backend, ce qui se produit rarement.
A ma connaissance, les désactiver depuis le child theme devrait être possible en utilisant remove_filter ou remove_action, cependant, nous ne proposons pas de code personnalisé qui ne fait pas partie de notre service d'assistance.
Mon conseil est d'essayer simplement sur un environnement local ou de staging et d'exécuter une sauvegarde.
Merci Ilyes pour les retours détaillés, c'est plus clair pour moi. Je pense qu'avec tout ça j'ai les infos dont j'ai besoin pour essayer d'identifier mieux ce problème et de l'éliminer en cas de besoin !
