Ottimizzazione delle performance di BuddyBoss

Oggi le prestazioni dei siti web sono fondamentali per garantire un’esperienza utente fluida e coinvolgente. BuddyBoss, una piattaforma potente per la creazione di comunità online basate su WordPress, non fa eccezione. Ottimizzare le performance di BuddyBoss può fare la differenza tra un sito lento e uno reattivo, migliorando il posizionamento sui motori di ricerca e aumentando la soddisfazione degli utenti. In questo articolo, esploreremo il nostro servizio di ottimizzazione ByddyBoss per potenziare la velocità e l’efficienza di BuddyBoss, assicurando che il vostro sito offra sempre il massimo delle prestazioni.

Cos’è BuddyBoss ?

BuddyBoss è una piattaforma robusta e flessibile progettata per creare e gestire comunità online, corsi e-learning, e siti di membership. Basato su WordPress, BuddyBoss offre una vasta gamma di funzionalità che facilitano l’interazione tra gli utenti, come forum, gruppi, profili personalizzati, e messaggistica privata. Grazie alla sua perfetta integrazione con plugin e temi popolari, BuddyBoss permette di estendere facilmente le capacità del sito, rendendolo una soluzione ideale per educatori, imprenditori e creatori di contenuti. Che si tratti di costruire una rete sociale per un gruppo di nicchia o di sviluppare un portale educativo completo, BuddyBoss offre gli strumenti necessari per creare un’esperienza utente coinvolgente e dinamica. Inoltre, la piattaforma fornisce un ambiente sicuro e personalizzabile, favorendo la collaborazione e la condivisione di conoscenze. Per maggiori dettagli, visita il sito ufficiale di BuddyBoss qui.

Requisiti per BuddyBoss

Per garantire un funzionamento ottimale di BuddyBoss, è fondamentale disporre di una configurazione server adeguata, soprattutto in base al numero di iscritti. BuddyBoss è un software esoso in termini di risorse, richiedendo una notevole potenza di CPU e RAM. Per comunità con meno di 1.000 iscritti, BuddyBoss nel sito ufficiale consiglia un server con almeno 4 GB di RAM e una CPU multi-core. Per siti con 1.000-10.000 iscritti, è preferibile avere almeno 8 GB di RAM e una CPU con performance elevate. Per comunità più grandi, oltre i 10.000 iscritti, è necessario considerare soluzioni server dedicate o cloud con almeno 16 GB di RAM e CPU di fascia alta.

Tuttavia è pacifico considerare che i requisiti hardware indicati dal produttore siano aneddoticamente sottodimensionati, forse perchè in fase di analisi iniziale, che è anche la fase pre vendita, qualora si indicassero soluzioni tecnicamente maggiori, ben dimensionate  e dunque più costose, potrebbe presentare un deterrente all’acquisto del plugin e pertanto è commercialmente più vantaggioso menzionare soluzioni economiche inizialmente, finalizzare la vendita e solo dopo mettere l’acquirente di fronte alla realtà in termini di carico e risorse hardware.

Un esempio concreto di queste esigenze viene da un nostro cliente (protetto da NDA) che gestisce una community di 10.000 utenti, integrando diverse funzionalità di BuddyBoss con LearnDash (LearnDash è un potente plugin per WordPress che permette di creare e vendere corsi online, offrendo funzionalità avanzate come quiz, certificati e progressi degli utenti). Per supportare questa configurazione complessa e garantire un’esperienza utente fluida, la soluzione adottata è stata quella di utilizzare un server con ben 32 core e 64 thread, 128 GB di RAM e 2 dischi NVMe SSD in RAID 1.

Questa configurazione avanzata è necessaria poiché BuddyBoss, richiedendo il login degli utenti nella propria area riservata, non consente l’uso di tecniche di caching standard come i plugin WP Rocket o Full Page Cache come Varnish, che risulterebbero del tutto inutili per gli utenti loggati. Questo implica che la configurazione del server deve essere ottimizzata per gestire carichi dinamici elevati, garantendo sempre una risposta rapida e un’esperienza utente fluida anche sotto stress elevato.

L’inutilità dei plugin di Cache, delle Cache Lato server e dei consigli ufficiali.

Quando si tratta di ottimizzare le prestazioni di BuddyBoss, è importante comprendere che l’uso di plugin di cache comuni e delle cache lato server può risultare del tutto inefficace. Plugin come WP Fastest Cache, SuperCache, WP Rocket, e W3 Total Cache sono strumenti potenti per molti siti WordPress, poiché permettono di ridurre i tempi di caricamento delle pagine memorizzando versioni statiche delle stesse. Allo stesso modo, soluzioni di cache lato server come Varnish Cache e NGINX Proxy Cache sono frequentemente utilizzate per migliorare le performance complessive delle applicazioni web. Tuttavia, BuddyBoss ha una caratteristica distintiva che complica l’uso di queste tecniche: la necessità per gli utenti di essere loggati nella loro area riservata.

Quando un utente è loggato, ogni pagina visualizzata è altamente personalizzata e dinamica, contenente informazioni specifiche per quell’utente, come notifiche, messaggi, attività recenti e molto altro. Questo significa che le tecniche di Full Page Cache, che memorizzano versioni statiche delle pagine per accelerarne il caricamento, non possono essere utilizzate efficacemente. Le soluzioni di caching menzionate sopra, che funzionano bene per contenuti statici, diventano inutili in un contesto dove ogni richiesta al server deve essere elaborata in modo unico.

Di conseguenza, per garantire prestazioni ottimali con BuddyBoss, è necessario investire in hardware potente e in un’ottimizzazione a livello applicativo.

I consigli ufficiali di BuddyBoss sottolineano l’importanza di un’ottimizzazione a livello di database e applicativo piuttosto che affidarsi esclusivamente a soluzioni di caching, tuttavia sono consigli molto basilari e poco tecnici ed il malcontento degli utilizzatori di BuddyBoss nelle grandi community è sempre molto frequente.

In Managed Server Srl, abbiamo pertanto voluto rendere disponibile un servizio di ottimizzazione delle prestazioni per BuddyBoss, che abbia come scopo oltre alla solita ottimizzazione per WordPress, anche un approccio applicativo per l’ottimizzazione delle performance applicative di BuddyBoss e dell’ecosistema adiacente, come ad esempio WooCommerce, LearnDash, BuddyPress e plugin più o meno differenti che possono essere utilizzati nella realizzazoine di una community con BuddyBoss.

Un caso reale di ottimizzazione BuddyBoss

Abbiamo da qualche mese un nuovo cliente operante nel settore della formazione con una community di oltre 10 mila membri, l’offerta formativa viene realizzata con una combinazione di Plugin come LearnDash, WooCommerce, UCanTinny, WooCommerce, e molti molti altri. Il cliente ha girato diversi fornitori di Hosting e consulenza sistemistica, tuttavia eccetto Cache lato server nessuno di loro si mai concentrato sul concetto precedentemente espresso, ovvero che BuddyBoss (così come tutti i siti che prevedono il login dell’utente) beneficiano in modo importante delle tecnologie di Full Page cache.

Va detto che normalmente le aziende di sistemistica non hanno in organico competenze di sviluppo, e che allo stesso modo le aziende di sviluppo non hanno competenza di sistemica. Questa lacuna tende molto spesso a non avere una visione di insieme, nell’ottica delle performance lato server e delle performance applicative.

Si finisce spesso in una situazione di scaricabarile dove lo sviluppatore afferma che il sito è lento per colpa del server e del reparto sistemistico, e il sistemista finisce con accusare lo sviluppatore e l’applicativo che è tremendamente lento e poco ottimizzato.

Se dovessimo schierarci in mezzo a queste due letture, certamente saremo a favore del sistemista e non solo per vicinanza e solidarietà professionale. E’ infatti innegabile che un pachiderma come BuddyBoss non brilli di performance e velocità essendo a sua volta sviluppato su WordPress con tecnologie lente come PHP e MySQL piuttosto che i più moderni Go, Node.js con magari qualche DB NOSQL come MongoDB o Cassandra.

Tuttavia bisogna anche mettersi nelle vesti del cliente finale, che spesso non è un tecnico, ma un imprenditore che ambisce a cercare di ottenere i migliori risultati possibili con gli strumenti (spesso scelti da altri) che si ritrova.

Quello che bisogna fare insomma è uscire dalla logica dello scarica barile in cui perdono tutti, ma provare ad offrire il miglior supporto, server, sistemistico ed applicativo al fine di ottenere le migliori performance ottenibili, giocandosi tutte le carte possibili ed anche eventuali assi nella manica.

Hardware potente e ben dimensionato a costi accessibili.

Come anticipato, BuddyBoss richiede un substrato hardware potente e ben dimensionato per garantire prestazioni ottimali. Tuttavia, la stessa configurazione hardware può avere costi molto differenti in base al fornitore di servizi e al datacenter scelto. Se state pensando di installare BuddyBoss su un’istanza cloud, è probabile che non abbiate idea della significativa differenza di costi tra un’istanza bare metal e un’istanza cloud con caratteristiche equivalenti. Le istanze bare metal spesso offrono prestazioni superiori a costi inferiori rispetto alle loro controparti cloud, specialmente quando si considerano le necessità di risorse elevate come quelle richieste da BuddyBoss.

Anche nel caso di un server dedicato, è essenziale sapere dove acquistare per ottenere il miglior rapporto qualità-prezzo. È fondamentale scegliere datacenter certificati ISO27001 e GDPR Compliant per garantire sicurezza e conformità alle normative, senza dover spendere una fortuna. La scelta del datacenter giusto non solo influisce sui costi, ma anche sull’affidabilità e la sicurezza del servizio.

La nostra esperienza, maturata sin dal 2005, ci ha permesso di affrontare numerose sfide professionali nel settore dell’hosting e della sistemistica Linux. Grazie a questa vasta esperienza, siamo in grado di selezionare il miglior datacenter e le migliori tecnologie hardware lato server per le vostre esigenze, garantendo prestazioni elevate e sicurezza a costi accessibili. Come vendor indipendenti, possiamo confrontare offerte e scegliere le soluzioni più adatte, evitando sovrapprezzi inutili e assicurando che il vostro investimento in hardware sia ottimizzato al massimo.

Tuning ed ottimizzazione lato server.

Uno stack software lato server ben configurato è di fondamentale importanza per garantire le migliori prestazioni di BuddyBoss. La scelta dei giusti software e una loro configurazione ottimale possono fare la differenza tra un sito mediamente performante e uno eccezionalmente veloce e stabile. Ad esempio, c’è una notevole differenza tra installare uno stack con NGINX, PHP-FPM, MariaDB e Varnish in modo standard e configurare lo stesso stack con un tuning approfondito del filesystem, del database e dell’interprete PHP per massimizzare le prestazioni.

Ottimizzare lo stack server significa andare oltre la semplice installazione dei software. È necessario effettuare un tuning preciso del filesystem per migliorare la gestione dei file e l’I/O, configurare il database per ottimizzare le query e la gestione delle transazioni, e regolare PHP-FPM per gestire meglio i processi e la memoria. Questo tipo di ottimizzazione richiede una conoscenza approfondita di come funzionano i vari componenti e di come interagiscono tra loro.

Abbiamo maturato ampia esperienza nel tuning lato server, in particolare con il motore InnoDB e AriaDB utilizzati da DBMS come Percona Server o MariaDB. Questi motori di database, quando configurati correttamente, possono offrire prestazioni significativamente superiori, riducendo i tempi di risposta e migliorando la capacità di gestione delle transazioni. La nostra esperienza ci permette di ottimizzare questi componenti per ottenere il massimo dalle risorse hardware disponibili, migliorando la velocità e la stabilità complessiva del sistema.

Profilazione dell’applicazione con New Relic (o qualsiasi altro APM)

L’ottimizzazione applicativa di BuddyBoss richiede un approccio approfondito per identificare e risolvere i colli di bottiglia nelle prestazioni. Una delle tecniche più efficaci per raggiungere questo obiettivo è la profilazione dell’applicazione utilizzando strumenti di Application Performance Management (APM) come New Relic. New Relic, e altri APM simili, offrono una panoramica dettagliata delle performance dell’applicazione, consentendo di monitorare il comportamento in tempo reale e di analizzare le metriche chiave.

Con New Relic, è possibile tracciare le richieste degli utenti e visualizzare come ogni componente del sistema risponde. Questo strumento fornisce informazioni cruciali sulle prestazioni del server, del database e del codice applicativo, evidenziando le aree che necessitano di miglioramenti. Ad esempio, New Relic può aiutare a identificare query SQL lente, funzioni PHP inefficienti o componenti di terze parti che impattano negativamente sui tempi di risposta.

Per BuddyBoss, dove ogni richiesta degli utenti loggati deve essere processata in modo dinamico, l’uso di un APM è essenziale. New Relic permette di individuare le query del database che causano rallentamenti, monitorare le chiamate AJAX, e capire quali parti del codice consumano più risorse CPU e memoria. Questi dati permettono agli amministratori di sistema e agli sviluppatori di prendere decisioni informate per ottimizzare il codice, migliorare la configurazione del database e regolare le risorse del server.

Un esempio concreto potrebbe essere la riduzione dei tempi di caricamento delle pagine del profilo utente in BuddyBoss. Attraverso la profilazione con New Relic, si potrebbe scoprire che una particolare query SQL richiede troppo tempo per essere eseguita. Con queste informazioni, è possibile ottimizzare la query, aggiungere indici appropriati o riprogettare la struttura del database per migliorare le performance.

Inoltre, New Relic consente di impostare alert personalizzati che avvisano immediatamente quando le prestazioni dell’applicazione degradano, permettendo interventi tempestivi per risolvere i problemi prima che impattino negativamente l’esperienza utente. Questa proattività è cruciale per mantenere un alto livello di soddisfazione degli utenti in una piattaforma complessa come BuddyBoss.

I risultati raggiunti dopo l’analisi e l’ottimizzazione dell’installazione BuddyBoss

Bisogna premettere che non è prassi per noi sistemisti con competenze applicative portare un applicativo WordPress o PHP su un APM come New Relic, equivale come per un meccanico smontare minuziosamente tutto il motore per poi riassemblarlo nel tentavi di comprendere la problematica e poi risolverlo. E’ un task estremamente dispendioso in termini di tempo e risorse, tuttavia è l’unica strada da intraprendere quando le classiche ottimizzazioni lato server su hardware potente non sembrano portare risultati apprezzabili all’installazione del cliente.

Bisogna spostarsi la mani ma è l’unica strada possibile, quella del misurare per decidere, ovvero comprendere i colli di bottiglia e l’origine del problema e poi procedere con la risoluzione.

Possiamo osservare dallo screenshot sopra che, nelle prime ore del mattino, il carico del server e il numero di transazioni erano estremamente elevati, con tempi di risposta molto lenti. Le medie si attestavano intorno ai 20 secondi, con picchi che superavano i 60 secondi, rendendo di fatto il backend lento o addirittura inutilizzabile. Questo rallentamento influiva negativamente sull’esperienza degli utenti amministratori, causando frustrazione e inefficienza.

Il tracing, come evidenziato nell’immagine seguente, rivelava che ogni chiamata admin-ajax impiegava oltre 70 secondi per completarsi. Considerando la frequenza con cui queste chiamate vengono effettuate dagli utenti loggati, il risultato era un accumulo di carico significativo, che degradava ulteriormente le performance del sistema. Questo causava un’esperienza utente estremamente scadente, con tempi di attesa insostenibili.

La causa principale di questi problemi era almeno apparentemente il plugin “CRM Multistep Subscription”, che presentava chiari problemi di performance. Sebbene non fosse immediatamente evidente quali fossero i difetti specifici, era chiaro che il plugin introduceva dei refusi e inefficienze che dovevano essere affrontati. La nostra analisi approfondita e l’intervento mirato sono stati essenziali per identificare e risolvere queste criticità, migliorando così significativamente le prestazioni del sistema.

Una ulteriore analisi ci permetteva di comprendere come nello specifico il problema alla base era una query SQL non performante con un tempo di esecuzione di oltre 50 secondi ed imputabile questa volta a Learndash che interrogava il Database per recuperare i corsi associati ad ogni utente.

Considerando che la query era sempre la stessa e non aveva come clausole parametri o variabili specifici all’utente, la soluzione più veloce e funzionante è stato quello di procedere oltre che aggiungere alcuni indici alle tabelle MySQL (nello specifico MariaDB 11.4), quello di modificare il codice applicativo incriminato utilizzando una Cache lato codice.

Abbiamo pertanto individuato il codice incriminato che vedete seguentemente:

e lo abbiamo riscritto aggiungendo funzionalità di caching delle query a livello di codice PHP utilizzando wp_cache_set() e wp_cache_get() di WordPress.

Per integrare una cache delle query nella funzione learndash_get_courses_count, possiamo utilizzare l’API di cache di WordPress. Questo ci permette di memorizzare i risultati delle query per un certo periodo di tempo, migliorando le prestazioni.

wp_cache_set() è una funzione di WordPress che consente di memorizzare un valore nella cache. Si utilizza passando una chiave univoca, il valore da memorizzare, un gruppo opzionale per organizzare i dati e un tempo di scadenza opzionale. Questa funzione memorizza il valore fornito nella cache con la chiave specificata.

wp_cache_get() è la funzione complementare che permette di recuperare un valore dalla cache. Si utilizza fornendo la chiave univoca e, opzionalmente, il gruppo a cui appartiene il valore. È possibile forzare il recupero dalla cache principale e verificare se il valore è stato trovato o meno. Questa funzione recupera il valore associato alla chiave specificata dalla cache.

Utilizzare wp_cache_set() e wp_cache_get() in WordPress in modo responsabile e ove possibile, aiuta a migliorare le performance del sito riducendo il carico sul database e velocizzando i tempi di risposta.

Nello specifico il codice che abbiamo modificato rispetto a quello originale che pretendeva di fare ogni volta una query da 50 secondi, si proponeva di memorizzare il risultato della query per 1 ora.

1. Generazione della chiave di cache: Viene generata una chiave univoca basata sugli argomenti della query e sul campo di ritorno.
2. Recupero dalla cache: Si tenta di recuperare il risultato dalla cache utilizzando la chiave generata. Se il risultato è presente nella cache, viene restituito immediatamente.
3. Memorizzazione nella cache: Se il risultato non è presente nella cache, viene eseguita la query e il risultato viene memorizzato nella cache per 1 ora

In questo modo, i risultati delle query vengono memorizzati e riutilizzati, migliorando le prestazioni complessive.

Il risultato è che la query lenta è di fatto scomparsa. Se andiamo a vedere l’ultima volta che è comparsa la query lenta nel sistema di analisi di New Relic, vediamo che l’ultima volta che è apparsa è stata 5 ore fa, poco prima della modifica risolutiva.

In questo modo come in un effetto a catena, le chiamate admin-ajax.php hanno iniziato a performare correttamente nonchè il carico a livello applicativo e lato server con un appiattimento delle richieste del DB e delle latenze.

I risultati ottenuti si sono tradotti in un abbattimento del carico della CPU passata da un Load Average di 30 ad un Load Average di 4, con un risparmio di oltre il 600%,  un aumento della reattività del sito per gli utenti loggati, minor carico sul database, ed un miglioramento generale davvero tangibile ad occhio nudo.