Optimizing BuddyBoss performance

Today, website performance is critical to ensuring a smooth and engaging user experience. BuddyBoss, a powerful platform for building WordPress-based online communities, is no exception. Optimizing BuddyBoss performance can make the difference between a slow site and a responsive one, improving your search engine rankings and increasing user satisfaction. In this article, we'll explore our ByddyBoss optimization service to boost the speed and efficiency of BuddyBoss, ensuring your site always delivers peak performance.

What is BuddyBoss?

BuddyBoss is a robust and flexible platform designed to create and manage online communities, e-learning courses, and membership sites. Based on WordPress, BuddyBoss offers a wide range of features that facilitate interaction between users, such as forums, groups, custom profiles, and private messaging. Thanks to its seamless integration with popular plugins and themes, BuddyBoss allows you to easily extend your site's capabilities, making it an ideal solution for educators, entrepreneurs and content creators. Whether building a social network for a niche group or developing a comprehensive educational portal, BuddyBoss offers the tools you need to create an engaging and dynamic user experience. Furthermore, the platform provides a secure and customizable environment, encouraging collaboration and knowledge sharing. For more details, visit the official BuddyBoss website , here.

Requirements for BuddyBoss

To ensure optimal functioning of BuddyBoss, it is essential to have an adequate server configuration, especially based on the number of subscribers. BuddyBoss is a resource-intensive software, requiring significant CPU and RAM power. For communities with fewer than 1.000 members, BuddyBoss on the official website recommends a server with at least 4 GB of RAM and a multi-core CPU. For sites with 1.000-10.000 subscribers, it is preferable to have at least 8 GB of RAM and a high-performance CPU. For larger communities, over 10.000 members, you need to consider dedicated or cloud server solutions with at least 16 GB of RAM and high-end CPU.

However, it is clear that the hardware requirements indicated by the manufacturer are anecdotally undersized, perhaps because in the initial analysis phase, which is also the pre-sales phase, if technically greater, well-sized and therefore more expensive solutions were indicated, it could present a deterrent to purchase of the plugin and therefore it is commercially more advantageous to mention economic solutions initially, finalize the sale and only then put the buyer face to face with reality in terms of load and hardware resources.

A concrete example of these needs comes from one of our clients (protected by NDA) who manages a community of 10.000 users, integrating various features of BuddyBoss with LearnDash (LearnDash is a powerful plugin for WordPress that allows you to create and sell online courses, offering functionalities advanced features such as quizzes, certificates and user progress). To support this complex configuration and guarantee a fluid user experience, the solution adopted was to use a server with 32 cores and 64 threads, 128 GB of RAM and 2 NVMe SSD disks in RAID 1.

This advanced configuration is necessary because BuddyBoss, by requiring users to log in to its private area, does not allow the use of standard caching techniques such as WP Rocket or Full Page Cache plugins such as Varnish, which would be completely useless for logged in users. This implies that the server configuration must be optimized to handle high dynamic loads, always ensuring fast response and a smooth user experience even under high stress.

The uselessness of Cache plugins, Server Side Caches and official advice.

When it comes to optimizing the performance of BuddyBoss, it is important to understand that using common caching plugins and server-side caches can be completely ineffective. Plugins like WP Fastest Cache, SuperCache, WP Rocket, and W3 Total Cache are powerful tools for many WordPress sites, as they allow you to reduce page loading times by storing static versions of them. Likewise, server-side caching solutions such as Varnish Cache and NGINX Proxy Cache are frequently used to improve the overall performance of web applications. However, BuddyBoss has a distinctive feature that complicates the use of these techniques: the need for users to be logged into their private area.

When a user is logged in, each page viewed is highly personalized and dynamic, containing information specific to that user, such as notifications, messages, recent activity and much more. This means that Full Page Cache techniques, which store static versions of pages to speed up loading, cannot be used effectively. The caching solutions mentioned above, which work well for static content, become useless in a context where each request to the server must be processed uniquely.

As a result, to ensure optimal performance with BuddyBoss, you need to invest in powerful hardware and application-level optimization.

The official BuddyBoss advice underlines the importance of optimization at the database and application level rather than relying exclusively on caching solutions, however it is very basic and not very technical advice and the discontent of BuddyBoss users in large communities is always very frequent .

At Managed Server Srl, we therefore wanted to make a performance optimization service available for BuddyBoss, which has as its aim, in addition to the usual optimization for WordPress, also an application approach for optimizing the application performance of BuddyBoss and the adjacent ecosystem, such as WooCommerce, LearnDash, BuddyPress and more or less different plugins that can be used in the building a community with BuddyBoss.

A real case of BuddyBoss optimization

For a few months we have had a new client operating in the training sector with a community of over 10 thousand members, the training offer is created with a combination of plugins such as LearnDash, WooCommerce, UCanTinny, WooCommerce, and many many others. The client visited various hosting and system consultancy providers, however, with the exception of server-side cache, none of them ever focused on the concept previously expressed, that is, that BuddyBoss (as well as all sites that require user login) benefit significantly from the Full Page cache technologies.

It must be said that systems companies do not normally have development skills on staff, and that development companies similarly do not have systems skills. This gap very often tends not to have an overall vision, from the perspective of server-side performance and application performance.

We often end up in a buck-passing situation where the developer claims that the site is slow due to the server and the systems department, and the systems engineer ends up accusing the developer and the application which is terribly slow and poorly optimized.

If we were to take sides between these two readings, we will certainly be in favor of the systems engineer and not only out of professional closeness and solidarity. It is in fact undeniable that a pachyderm like BuddyBoss does not shine in performance and speed as it is in turn developed on WordPress with slow technologies such as PHP and MySQL rather than the more modern Go, Node.js with perhaps some NOSQL DB such as MongoDB or Cassandra.

However, we must also put ourselves in the shoes of the end customer, who is often not a technician, but an entrepreneur who aims to try to obtain the best possible results with the tools (often chosen by others) that he finds.

In short, what we need to do is to get away from the buck-passing logic in which everyone loses, but try to offer the best server, system and application support in order to obtain the best performance achievable, playing all possible cards and also any aces up the sleeve. .

Powerful, well-sized hardware at affordable costs.

As anticipated, BuddyBoss requires a powerful and well-sized hardware substrate to ensure optimal performance. However, the same hardware configuration can have very different costs depending on the service provider and data center you choose. If you're thinking about installing BuddyBoss on a cloud instance, chances are you have no idea about the significant cost difference between a bare metal instance and a cloud instance with equivalent features. Bare metal instances often offer superior performance at lower costs than their cloud counterparts, especially when considering high resource needs like those required by BuddyBoss.

Even in the case of a dedicated server, it is essential to know where to buy to get the best value for money. It is essential to choose ISO27001 and GDPR Compliant data centers to ensure security and regulatory compliance, without having to spend a fortune. Choosing the right data center not only affects costs, but also the reliability and security of the service.

Our experience, gained since 2005, has allowed us to face numerous professional challenges in the Linux hosting and system engineering sector. Thanks to this vast experience, we are able to select the best datacenter and server-side hardware technologies for your needs, ensuring high performance and security at affordable costs. As independent vendors, we can compare offers and choose the most suitable solutions, avoiding unnecessary surcharges and ensuring that your hardware investment is maximized.

Server-side tuning and optimization.

A well-configured server-side software stack is crucial to ensuring the best performance of BuddyBoss. Choosing the right software and their optimal configuration can make the difference between an average performing site and an exceptionally fast and stable one. For example, there is a noticeable difference between installing a stack with NGINX, PHP-FPM, MariaDB and Varnish in a standard way and configuring the same stack with extensive tuning of the filesystem, database and PHP interpreter to maximize performance.

Optimizing the server stack means going beyond simple software installation. You need to fine-tune the filesystem to improve file handling and I/O, configure the database to optimize query and transaction handling, and tune PHP-FPM to better manage processes and memory. This type of optimization requires in-depth knowledge of how the various components work and how they interact with each other.

We have gained extensive experience in server-side tuning, in particular with the InnoDB and AriaDB engines used by DBMSs such as Percona Server or MariaDB. These database engines, when configured correctly, can deliver significantly higher performance, reducing response times and improving transaction handling capacity. Our experience allows us to optimize these components to get the most out of the available hardware resources, improving the overall speed and stability of the system.

Application Profiling with New Relic (or any other APM)

BuddyBoss application optimization requires an in-depth approach to identify and resolve performance bottlenecks. One of the most effective techniques to achieve this is application profiling using Application Performance Management (APM) tools such as New Relic. New Relic, and other similar APMs, offer a detailed overview of application performance, allowing you to monitor behavior in real time and analyze key metrics.

With New Relic, you can track user requests and view how each component of the system responds. This tool provides crucial information about the performance of your server, database and application code, highlighting areas that need improvement. For example, New Relic can help identify slow SQL queries, inefficient PHP functions, or third-party components that negatively impact response times.

For BuddyBoss, where every request from logged in users must be processed dynamically, the use of an APM is essential. New Relic allows you to identify database queries that cause slowdowns, monitor AJAX calls, and understand which parts of the code consume the most CPU and memory resources. This data allows system administrators and developers to make informed decisions to optimize code, improve database configuration, and adjust server resources.

A concrete example could be reducing the loading times of user profile pages in BuddyBoss. Through profiling with New Relic, you may find that a particular SQL query takes too long to execute. With this information, you can optimize the query, add appropriate indexes, or redesign the database structure to improve performance.

Furthermore, New Relic allows you to set custom alerts that immediately notify you when application performance degrades, allowing timely interventions to resolve problems before they negatively impact the user experience. This proactivity is crucial to maintaining a high level of user satisfaction in a complex platform like BuddyBoss.

The results achieved after analyzing and optimizing the BuddyBoss installation

We must start by saying that it is not standard practice for us systems engineers with application skills to port a WordPress or PHP application to an APM like New Relic, it is equivalent to a mechanic meticulously dismantling the entire engine and then reassembling it in an attempt to understand the problem and then resolve it. It is an extremely expensive task in terms of time and resources, however it is the only path to take when the classic server-side optimizations on powerful hardware do not seem to bring appreciable results to the customer's installation.

You have to move your hands but it is the only possible path, that of measuring to decide, that is, understanding the bottlenecks and the origin of the problem and then proceeding with the resolution.

We can observe from the screenshot above that, in the early hours of the morning, the server load and number of transactions were extremely high, with very slow response times. The averages were around 20 seconds, with peaks exceeding 60 seconds, effectively making the backend slow or even unusable. This slowdown negatively impacted the administrator user experience, causing frustration and inefficiency.

Tracing, as highlighted in the image below, revealed that each admin-ajax call took over 70 seconds to complete. Considering the frequency with which these calls are made by logged in users, the result was a significant load build-up, further degrading system performance. This caused an extremely poor user experience, with unsustainable waiting times.

The main cause of these problems was at least apparently the “CRM Multistep Subscription” plugin, which had clear performance problems. While it wasn't immediately apparent what the specific flaws were, it was clear that the plugin introduced typos and inefficiencies that needed to be addressed. Our in-depth analysis and targeted intervention were essential to identifying and resolving these issues, thereby significantly improving system performance.

A further analysis allowed us to understand how specifically the underlying problem was a non-performing SQL query with an execution time of over 50 seconds and attributable this time to Learndash which queried the Database to retrieve the courses associated with each user.

Considering that the query was always the same and did not have user-specific parameters or variables as clauses, the fastest and most effective solution was to proceed as well as add some indexes to the MySQL tables (specifically MariaDB 11.4), to modify the offending application code using a Code Side Cache.

We have therefore identified the offending code that you see below:

and we rewrote it by adding query caching functionality at the PHP code level using WordPress's wp_cache_set() and wp_cache_get().

To integrate a query cache into your function learndash_get_courses_count, we can use the WordPress cache API. This allows us to store query results for a certain period of time, improving performance.

wp_cache_set() is a WordPress feature that allows you to cache a value. It is used by passing a unique key, the value to store, an optional group to organize the data, and an optional expiration time. This function caches the provided value with the specified key.

wp_cache_get() is the complementary function that allows you to retrieve a value from the cache. It is used by providing the unique key and, optionally, the group to which the value belongs. You can force fetch from main cache and check whether the value was found or not. This function retrieves the value associated with the specified key from the cache.

Use wp_cache_set() e wp_cache_get() in WordPress responsibly and where possible, helps improve site performance by reducing the load on the database and speeding up response times.

Specifically, the code that we modified compared to the original one which claimed to make a 50 second query each time, aimed to store the result of the query for 1 hour.

1. Cache key generation: A unique key is generated based on the query arguments and return field.
2. Recovering from cache: Attempts to retrieve the result from the cache using the generated key. If the result is present in the cache, it is returned immediately.
3. Caching: If the result is not in the cache, the query is executed and the result is cached for 1 hour

This way, query results are stored and reused, improving overall performance.

The result is that the slow query has effectively disappeared. If we look at the last time the slow query appeared in the New Relic analysis system, we see that the last time it appeared was 5 hours ago, shortly before the final change.

In this way, as in a chain effect, the admin-ajax.php calls began to perform correctly as well as the load at the application and server level with a flattening of DB requests and latencies.

The results obtained translated into a reduction in the CPU load from a Load Average of 30 to a Load Average of 4, with a saving of over 600%, an increase in the responsiveness of the site for logged in users, less load on the database, and a general improvement that is truly tangible to the naked eye.