Table des matières de l'article :
Aujourd’hui, les performances d’un site Web sont essentielles pour garantir une expérience utilisateur fluide et engageante. BuddyBoss, une plateforme puissante pour créer des communautés en ligne basées sur WordPress, ne fait pas exception. L'optimisation des performances de BuddyBoss peut faire la différence entre un site lent et un site réactif, en améliorant votre classement dans les moteurs de recherche et en augmentant la satisfaction des utilisateurs. Dans cet article, nous explorerons notre service d'optimisation ByddyBoss pour augmenter la vitesse et l'efficacité de BuddyBoss, garantissant ainsi que votre site offre toujours des performances optimales.
Qu’est-ce que BuddyBoss ?
BuddyBoss est une plateforme robuste et flexible conçue pour créer et gérer des communautés en ligne, des cours d'apprentissage en ligne et des sites d'adhésion. Basé sur WordPress, BuddyBoss propose un large éventail de fonctionnalités qui facilitent l'interaction entre les utilisateurs, telles que des forums, des groupes, des profils personnalisés et une messagerie privée. Grâce à son intégration transparente avec les plugins et thèmes populaires, BuddyBoss vous permet d'étendre facilement les capacités de votre site, ce qui en fait une solution idéale pour les éducateurs, les entrepreneurs et les créateurs de contenu. Qu'il s'agisse de créer un réseau social pour un groupe de niche ou de développer un portail éducatif complet, BuddyBoss offre les outils dont vous avez besoin pour créer une expérience utilisateur engageante et dynamique. De plus, la plateforme offre un environnement sécurisé et personnalisable, encourageant la collaboration et le partage des connaissances. Pour plus de détails, visitez le site officiel de BuddyBoss ici.
Conditions requises pour BuddyBoss
Pour assurer un fonctionnement optimal de BuddyBoss, il est essentiel d'avoir une configuration de serveur adéquate, notamment en fonction du nombre d'abonnés. BuddyBoss est un logiciel gourmand en ressources, nécessitant une puissance CPU et RAM importante. Pour les communautés de moins de 1.000 4 membres, BuddyBoss sur le site officiel recommande un serveur avec au moins 1.000 Go de RAM et un processeur multicœur. Pour les sites comptant entre 10.000 8 et 10.000 16 abonnés, il est préférable de disposer d'au moins XNUMX Go de RAM et d'un processeur performant. Pour les communautés plus grandes, comptant plus de XNUMX XNUMX membres, vous devez envisager des solutions de serveur dédié ou cloud avec au moins XNUMX Go de RAM et un processeur haut de gamme.
Cependant, il est clair que les exigences matérielles indiquées par le fabricant sont anecdotiquement sous-dimensionnées, peut-être parce que dans la phase d'analyse initiale, qui est également la phase d'avant-vente, si des solutions techniquement plus grandes, bien dimensionnées et donc plus coûteuses étaient indiquées, il pourrait avoir un effet dissuasif sur l'achat du plugin et il est donc commercialement plus avantageux d'évoquer dans un premier temps des solutions économiques, de finaliser la vente et seulement ensuite de mettre l'acheteur face à la réalité en termes de charge et de ressources matérielles.
Un exemple concret de ces besoins nous vient d'un de nos clients (protégé par NDA) qui gère une communauté de 10.000 XNUMX utilisateurs, intégrant diverses fonctionnalités de BuddyBoss avec LearnDash (LearnDash est un puissant plugin pour WordPress qui permet de créer et de vendre des cours en ligne, offrant des fonctionnalités avancées telles que des quiz, des certificats et la progression des utilisateurs). Pour supporter cette configuration complexe et garantir une expérience utilisateur fluide, la solution adoptée a été d'utiliser un serveur avec 32 cœurs et 64 threads, 128 Go de RAM et 2 disques SSD NVMe en RAID 1.
Cette configuration avancée est nécessaire car BuddyBoss, en obligeant les utilisateurs à se connecter à son espace privé, ne permet pas l'utilisation de techniques de cache standards comme WP Rocket ou de plugins Full Page Cache comme Varnish, qui seraient totalement inutiles pour les utilisateurs connectés. . Cela implique que la configuration du serveur doit être optimisée pour gérer des charges dynamiques élevées, garantissant toujours une réponse rapide et une expérience utilisateur fluide, même sous un stress élevé.
L'inutilité des plugins Cache, des Server Side Caches et des conseils officiels.
Lorsqu'il s'agit d'optimiser les performances de BuddyBoss, il est important de comprendre que l'utilisation de plugins de mise en cache courants et de caches côté serveur peut être totalement inefficace. Des plugins comme WP Fastest Cache, SuperCache, WP Rocket et W3 Total Cache sont des outils puissants pour de nombreux sites WordPress, car ils vous permettent de réduire les temps de chargement des pages en en stockant des versions statiques. De même, les solutions de mise en cache côté serveur telles que Varnish Cache et NGINX Proxy Cache sont fréquemment utilisées pour améliorer les performances globales des applications Web. Cependant, BuddyBoss possède une particularité qui complique l'utilisation de ces techniques : la nécessité pour les utilisateurs d'être connectés à leur espace membre.
Lorsqu'un utilisateur est connecté, chaque page consultée est hautement personnalisée et dynamique, contenant des informations spécifiques à cet utilisateur, telles que des notifications, des messages, une activité récente et bien plus encore. Cela signifie que les techniques de cache complet, qui stockent des versions statiques des pages pour accélérer le chargement, ne peuvent pas être utilisées efficacement. Les solutions de mise en cache mentionnées ci-dessus, qui fonctionnent bien pour les contenus statiques, deviennent inutiles dans un contexte où chaque requête adressée au serveur doit être traitée de manière unique.
Par conséquent, pour garantir des performances optimales avec BuddyBoss, vous devez investir dans du matériel puissant et dans une optimisation au niveau des applications.
Les conseils officiels de BuddyBoss soulignent l'importance de l'optimisation au niveau de la base de données et des applications plutôt que de s'appuyer exclusivement sur des solutions de mise en cache, cependant ce sont des conseils très basiques et peu techniques et le mécontentement des utilisateurs de BuddyBoss dans les grandes communautés est toujours très fréquent.
Chez Managed Server Srl, nous avons donc voulu mettre à disposition un service d'optimisation des performances pour BuddyBoss, qui a pour objectif, outre l'optimisation habituelle pour WordPress, également une approche applicative pour optimiser les performances des applications de BuddyBoss et de l'écosystème adjacent, comme WooCommerce, LearnDash, BuddyPress et des plugins plus ou moins différents pouvant être utilisés dans la construction d'une communauté avec BuddyBoss.
Un cas réel d'optimisation BuddyBoss
Depuis quelques mois nous avons un nouveau client opérant dans le secteur de la formation avec une communauté de plus de 10 mille membres, l'offre de formation est créée avec une combinaison de plugins tels que LearnDash, WooCommerce, UCanTinny, WooCommerce et bien d'autres. Le client a consulté plusieurs fournisseurs d'hébergement et de conseil système, mais aucun d'entre eux, à l'exception du cache côté serveur, ne s'est jamais concentré sur le concept exprimé précédemment, à savoir que BuddyBoss (ainsi que tous les sites qui nécessitent une connexion utilisateur) bénéficient de manière significative de la Technologies de cache pleine page.
Il faut dire que les sociétés de systèmes ne disposent généralement pas de compétences en développement parmi leur personnel, et que les sociétés de développement ne disposent pas non plus de compétences en systèmes. Cet écart a très souvent tendance à ne pas avoir une vision globale, du point de vue des performances côté serveur et des performances applicatives.
On se retrouve souvent dans une situation de rejet de la responsabilité où le développeur prétend que le site est lent à cause du serveur et du service système, et l'ingénieur système finit par accuser le développeur et l'application qui est terriblement lente et mal optimisée.
Si nous devions prendre parti entre ces deux lectures, nous serions certainement en faveur de l'ingénieur système et pas seulement par proximité et solidarité professionnelles. Il est en effet indéniable qu'un pachyderme comme BuddyBoss ne brille pas en termes de performances et de rapidité car il est lui-même développé sur WordPress avec des technologies lentes comme PHP et MySQL plutôt que sur Go, Node.js plus moderne avec peut-être quelques DB NOSQL comme MongoDB ou Cassandra.
Cependant, il faut aussi se mettre à la place du client final, qui n'est souvent pas un technicien, mais un entrepreneur qui vise à essayer d'obtenir les meilleurs résultats possibles avec les outils (souvent choisis par d'autres) qu'il trouve.
En bref, ce que nous devons faire, c'est sortir de la logique de rejet de la responsabilité dans laquelle tout le monde est perdant, mais essayer d'offrir le meilleur support serveur, système et applicatif afin d'obtenir les meilleures performances possibles, en jouant toutes les cartes possibles et aussi tous les as dans la manche.
Matériel puissant et de bonne taille à des coûts abordables.
Comme prévu, BuddyBoss nécessite un substrat matériel puissant et bien dimensionné pour garantir des performances optimales. Cependant, la même configuration matérielle peut avoir des coûts très différents selon le fournisseur de services et le centre de données que vous choisissez. Si vous envisagez d'installer BuddyBoss sur une instance cloud, il est probable que vous n'ayez aucune idée de la différence de coût significative entre une instance nue et une instance cloud dotée de fonctionnalités équivalentes. Les instances nues offrent souvent des performances supérieures à des coûts inférieurs à ceux de leurs homologues cloud, en particulier si l'on considère des besoins en ressources élevés comme ceux requis par BuddyBoss.
Même dans le cas d’un serveur dédié, il est essentiel de savoir où l’acheter pour obtenir le meilleur rapport qualité/prix. Il est essentiel de choisir des centres de données conformes aux normes ISO27001 et RGPD pour garantir la sécurité et la conformité réglementaire, sans avoir à dépenser une fortune. Le choix du bon centre de données affecte non seulement les coûts, mais également la fiabilité et la sécurité du service.
Notre expérience, acquise depuis 2005, nous a permis de relever de nombreux défis professionnels dans le secteur de l'hébergement et de l'ingénierie système Linux. Grâce à cette vaste expérience, nous sommes en mesure de sélectionner les meilleures technologies matérielles de centre de données et côté serveur pour vos besoins, garantissant ainsi des performances et une sécurité élevées à des coûts abordables. En tant que fournisseurs indépendants, nous pouvons comparer les offres et choisir les solutions les plus adaptées, évitant ainsi les suppléments inutiles et garantissant que votre investissement matériel est maximisé.
Réglage et optimisation côté serveur.
Une pile logicielle côté serveur bien configurée est cruciale pour garantir les meilleures performances de BuddyBoss. Choisir le bon logiciel et sa configuration optimale peut faire la différence entre un site aux performances moyennes et un site exceptionnellement rapide et stable. Par exemple, il existe une différence notable entre installer une pile avec NGINX, PHP-FPM, MariaDB et Varnish de manière standard et configurer la même pile avec un réglage approfondi du système de fichiers, de la base de données et de l'interpréteur PHP pour maximiser les performances.
Optimiser la pile de serveurs signifie aller au-delà de la simple installation de logiciels. Vous devez affiner le système de fichiers pour améliorer la gestion des fichiers et les E/S, configurer la base de données pour optimiser la gestion des requêtes et des transactions, et régler PHP-FPM pour mieux gérer les processus et la mémoire. Ce type d’optimisation nécessite une connaissance approfondie du fonctionnement des différents composants et de la manière dont ils interagissent les uns avec les autres.
Nous avons acquis une grande expérience dans le tuning côté serveur, notamment avec les moteurs InnoDB et AriaDB utilisés par les SGBD tels que Percona Server ou MariaDB. Ces moteurs de base de données, lorsqu'ils sont configurés correctement, peuvent offrir des performances nettement supérieures, réduisant les temps de réponse et améliorant la capacité de traitement des transactions. Notre expérience nous permet d'optimiser ces composants pour tirer le meilleur parti des ressources matérielles disponibles, améliorant ainsi la vitesse et la stabilité globales du système.
Profilage d'application avec New Relic (ou tout autre APM)
L'optimisation des applications BuddyBoss nécessite une approche approfondie pour identifier et résoudre les goulots d'étranglement en matière de performances. L'une des techniques les plus efficaces pour y parvenir est le profilage des applications à l'aide d'outils de gestion des performances des applications (APM) tels que New Relic. New Relic et d'autres APM similaires offrent un aperçu détaillé des performances des applications, vous permettant de surveiller le comportement en temps réel et d'analyser les indicateurs clés.
Avec New Relic, vous pouvez suivre les demandes des utilisateurs et voir comment chaque composant du système répond. Cet outil fournit des informations cruciales sur les performances de votre serveur, de votre base de données et du code de votre application, mettant en évidence les domaines qui doivent être améliorés. Par exemple, New Relic peut aider à identifier les requêtes SQL lentes, les fonctions PHP inefficaces ou les composants tiers qui ont un impact négatif sur les temps de réponse.
Pour BuddyBoss, où chaque demande des utilisateurs connectés doit être traitée de manière dynamique, l'utilisation d'un APM est essentielle. New Relic vous permet d'identifier les requêtes de base de données qui provoquent des ralentissements, de surveiller les appels AJAX et de comprendre quelles parties du code consomment le plus de ressources CPU et mémoire. Ces données permettent aux administrateurs système et aux développeurs de prendre des décisions éclairées pour optimiser le code, améliorer la configuration de la base de données et ajuster les ressources du serveur.
Un exemple concret pourrait être de réduire les temps de chargement des pages de profil utilisateur dans BuddyBoss. Grâce au profilage avec New Relic, vous constaterez peut-être qu'une requête SQL particulière prend trop de temps à s'exécuter. Avec ces informations, vous pouvez optimiser la requête, ajouter des index appropriés ou reconcevoir la structure de la base de données pour améliorer les performances.
De plus, New Relic vous permet de définir des alertes personnalisées qui vous avertissent immédiatement lorsque les performances de l'application se dégradent, permettant ainsi des interventions rapides pour résoudre les problèmes avant qu'ils n'aient un impact négatif sur l'expérience utilisateur. Cette proactivité est cruciale pour maintenir un haut niveau de satisfaction des utilisateurs sur une plateforme complexe comme BuddyBoss.
Les résultats obtenus après analyse et optimisation de l'installation de BuddyBoss
Il faut commencer par dire que ce n'est pas une pratique courante pour nous, ingénieurs système ayant des compétences en applications, de porter une application WordPress ou PHP vers un APM comme New Relic, cela équivaut à un mécanicien démontant méticuleusement tout le moteur puis le remontant dans une tentative. pour comprendre le problème et ensuite le résoudre. Il s'agit d'une tâche extrêmement coûteuse en termes de temps et de ressources, mais c'est la seule voie à suivre lorsque les optimisations classiques côté serveur sur du matériel puissant ne semblent pas apporter de résultats appréciables à l'installation du client.
Il faut bouger les mains mais c'est la seule voie possible, celle de mesurer pour décider, c'est-à-dire comprendre les goulots d'étranglement et l'origine du problème puis procéder à la résolution.
Nous pouvons observer sur la capture d'écran ci-dessus qu'au petit matin, la charge du serveur et le nombre de transactions étaient extrêmement élevés, avec des temps de réponse très lents. Les moyennes étaient d'environ 20 secondes, avec des pics dépassant 60 secondes, ce qui rendait le backend lent, voire inutilisable. Ce ralentissement a eu un impact négatif sur l'expérience utilisateur de l'administrateur, provoquant frustration et inefficacité.
Le traçage, comme le souligne l'image ci-dessous, a révélé que chaque appel admin-ajax prenait plus de 70 secondes. Compte tenu de la fréquence à laquelle ces appels sont effectués par les utilisateurs connectés, il en résulte une accumulation de charge importante, dégradant encore davantage les performances du système. Cela a entraîné une expérience utilisateur extrêmement mauvaise, avec des temps d’attente insoutenables.
La principale cause de ces problèmes était, du moins apparemment, le plugin « CRM Multistep Subscription », qui présentait des problèmes de performances évidents. Même si les défauts spécifiques n'étaient pas immédiatement évidents, il était clair que le plugin introduisait des fautes de frappe et des inefficacités qui devaient être corrigées. Notre analyse approfondie et notre intervention ciblée ont été essentielles pour identifier et résoudre ces problèmes, améliorant ainsi considérablement les performances du système.
Une analyse plus approfondie nous a permis de comprendre en quoi le problème sous-jacent était précisément une requête SQL non performante avec un temps d'exécution de plus de 50 secondes et imputable cette fois à Learndash qui a interrogé la Base de données pour récupérer les cours associés à chaque utilisateur.
Considérant que la requête était toujours la même et ne comportait pas de paramètres ou de variables spécifiques à l'utilisateur comme clauses, la solution la plus rapide et la plus efficace consistait à procéder ainsi qu'à ajouter des index aux tables MySQL (en particulier MariaDB 11.4), pour modifier le fichier incriminé. code d’application à l’aide d’un cache côté code.
Nous avons donc identifié le code incriminé que vous voyez ci-dessous :
et nous l'avons réécrit en ajoutant une fonctionnalité de mise en cache des requêtes au niveau du code PHP à l'aide de wp_cache_set() et wp_cache_get() de WordPress.
Pour intégrer un cache de requêtes dans votre fonction learndash_get_courses_count
, nous pouvons utiliser l'API de cache WordPress. Cela nous permet de stocker les résultats des requêtes pendant une certaine période de temps, améliorant ainsi les performances.
wp_cache_set()
est une fonctionnalité WordPress qui permet de mettre en cache une valeur. Il est utilisé en transmettant une clé unique, la valeur à stocker, un groupe facultatif pour organiser les données et un délai d'expiration facultatif. Cette fonction met en cache la valeur fournie avec la clé spécifiée.
wp_cache_get()
est la fonction complémentaire qui permet de récupérer une valeur du cache. Il est utilisé en fournissant la clé unique et, éventuellement, le groupe auquel appartient la valeur. Vous pouvez forcer la récupération à partir du cache principal et vérifier si la valeur a été trouvée ou non. Cette fonction récupère la valeur associée à la clé spécifiée du cache.
Utiliser wp_cache_set()
e wp_cache_get()
dans WordPress de manière responsable et dans la mesure du possible, contribue à améliorer les performances du site en réduisant la charge sur la base de données et en accélérant les temps de réponse.
Concrètement, le code que nous avons modifié par rapport à celui d'origine qui prétendait faire une requête de 50 secondes à chaque fois, visait à stocker le résultat de la requête pendant 1 heure.
- Génération de clé de cache: Une clé unique est générée en fonction des arguments de la requête et du champ de retour.
- Récupération à partir du cache: tente de récupérer le résultat du cache à l'aide de la clé générée. Si le résultat est présent dans le cache, il est renvoyé immédiatement.
- Mise en cache: Si le résultat n'est pas dans le cache, la requête est exécutée et le résultat est mis en cache pendant 1 heure
De cette façon, les résultats des requêtes sont stockés et réutilisés, améliorant ainsi les performances globales.
Le résultat est que la requête lente a effectivement disparu. Si nous regardons la dernière fois que la requête lente est apparue dans le système d'analyse New Relic, nous voyons que la dernière fois qu'elle est apparue, c'était il y a 5 heures, juste avant le changement final.
De cette manière, comme dans un effet de chaîne, les appels admin-ajax.php ont commencé à s'exécuter correctement ainsi que la charge au niveau de l'application et du serveur avec un aplatissement des requêtes BD et des latences.
Les résultats obtenus se traduisent par une réduction de la charge CPU d'une Charge Moyenne de 30 à une Charge Moyenne de 4, avec une économie de plus de 600%, une augmentation de la réactivité du site pour les utilisateurs connectés, une moindre charge sur la base de données. , et une amélioration générale vraiment tangible à l'œil nu.