Comment nous avons découvert des requêtes API lentes sur un site WordPress

Nous développons une plateforme éducative qui vous permet de :

Toutes les actions sur le contenu impliquent de grandes quantités de données et une communication active avec la base de données.

Quelque temps après le lancement test du projet, nous avons constaté que le chargement, la sauvegarde et le clonage des leçons prenaient trop de temps. Cela nous a incités à étudier le problème en détail et à rechercher des solutions basées sur les goulots d’étranglement identifiés.

Stack technique de la plateforme

Nous avons choisi Vue.js comme framework front-end, ce qui nous a permis de rendre l’interface utilisateur des fonctionnalités principales du projet réactive, à savoir les fonctionnalités de l’éditeur et de la présentation des leçons. La particularité de l’implémentation résidait dans la construction de la communication entre le client et le serveur sous forme de requêtes API. Les requêtes sont envoyées en grand nombre en raison de l’approche de gestion des publications dans le CMS sélectionné (WordPress), il n’était donc pas possible de réduire le nombre de requêtes. Cependant, la parallélisation et l’exécution asynchrone ont permis d’atteindre les résultats souhaités en termes de performance.

Serveur

L’architecture évolutive basée sur AWS nous a permis de nous assurer que la capacité du serveur était suffisante pour traiter un grand flux d’utilisateurs et garantir des performances décentes lors des pics de charge. Cependant, cette fois, la situation s’est avérée si imprévisible que la mise à l’échelle horizontale et verticale n’a donné aucun meilleur résultat.

La description initiale du problème expliquait que l’éditeur de leçons front-end développé ainsi que les pages d’édition des enregistrements dans le panneau d’administration prenaient trop de temps à charger. La première chose qui nous est venue à l’esprit était que le panneau d’administration était écrit en React et utilisait des requêtes API pour récupérer les catégories, les taxonomies et les étiquettes. Notre éditeur de leçons utilisait également des requêtes API pour lire et écrire le contenu des leçons.

Après avoir exploré l’onglet « réseau » dans les outils de développement du navigateur, nous avons constaté que toutes les requêtes asynchrones au serveur fonctionnaient comme prévu, à l’exception des requêtes API qui prenaient au moins 3 secondes chacune. Une vue détaillée de la requête a montré un TTFB élevé (temps jusqu’au premier octet), indiquant une lenteur côté backend ou serveur.

Il a été calculé empiriquement que quelles que soient les actions effectuées par le point de terminaison API, le résultat serait toujours le même – au moins 3 secondes de traitement, augmentant jusqu’à 5-6 secondes avec la croissance de la base de données.

Il convient de noter en particulier que la production s’est avérée être la phase la plus lente car elle contenait le plus grand volume de données – les publications et leurs métadonnées. Afin de vérifier que la vitesse de chargement diminuait à mesure que la quantité de données augmentait, la base de production a été déployée dans un environnement de test où nous avons obtenu la confirmation de cette théorie.

Nous nous posions constamment la même question :

Pourquoi la vitesse d’une requête API qui n’utilise pas la base de données lors du traitement de la logique interne est-elle affectée par la taille de la base de données ?

Il a donc été décidé de désactiver les plugins utilisés un par un afin de déterminer leur impact sur la vitesse de chargement. Le premier résultat est apparu après la désactivation du plugin LearnDash, dont le contenu est la base de toute la plateforme. La vitesse de traitement des requêtes API était instantanément 40 fois plus rapide ! Cependant, étant donné l’impossibilité d’abandonner le plugin et de recourir à la recherche d’analogues, l’investigation a continué.

En parcourant le code du plugin LearnDash, en commençant par l’initialisation et l’inclusion des fichiers, nous avons commenté de grands blocs de code et vérifié leur impact sur la vitesse. Une attention particulière a été accordée à la fonctionnalité REST API, où le premier hook est apparu. En commentant entièrement l’utilisation de l’API REST par le plugin, le problème a été résolu. Cependant, ce n’était pas non plus une solution viable. En avançant dans la chaîne, nous avons trouvé la raison de ce comportement.

Le plugin LearnDash utilisait le hook WordPress rest_api_init non seulement pour enregistrer ses propres points de terminaison API et leurs champs, mais aussi pour inclure des contrôleurs supplémentaires avec de la logique, dont l’un contenait une sélection séquentielle non optimisée et volumineuse à partir de plusieurs tables de la base de données. Ainsi, quelle que soit la fonction d’itinéraire API, cette sélection était effectuée à chaque fois que nous envoyions une requête API au serveur (et, comme mentionné ci-dessus, de nombreuses requêtes sont envoyées). La raison de cette approche n’était pas claire, cependant, une demande de clarification a été envoyée aux développeurs du plugin LearnDash dans l’espoir d’un correctif dans les futures versions.

La présence d’un filtre dans le code du plugin (fourni par l’équipe de support LearnDash en réponse à notre ticket) a permis de résoudre la situation sans problème et d’autoriser l’exclusion des contrôleurs chargés de logique avant leur chargement. C’est ce que nous avons fait pour le contrôleur problématique.

Réponse de

l’équipe de développement LearnDash

Nous avons mis à jour ceci et prévoyons de publier les modifications dans la prochaine version majeure.

Merci pour vos retours – l’équipe de développement en a tenu compte et a également ajouté ses propres améliorations.