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 user interaction, 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 the capabilities of your site, making it an ideal solution for educators, entrepreneurs, and content creators. Whether building a social network for a niche group or developing a full-fledged 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 several BuddyBoss features with LearnDash (LearnDash is a powerful WordPress plugin that allows you to create and sell online courses, offering advanced features such as quizzes, certificates, and user progress). To support this complex configuration and ensure a seamless user experience, the solution adopted was to use a server with 32 cores and 64 threads, 128 GB of RAM, and two NVMe SSDs 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 BuddyBoss performance, it's 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 reduce page load times by storing static versions of pages. Similarly, server-side caching solutions like 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 member 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 more. This means that full page caching 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 available a performance optimization service for BuddyBoss , which aims, 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 creating 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 mentioned, BuddyBoss requires powerful and well-sized hardware to ensure optimal performance. However, the same hardware configuration can have significantly different costs depending on the service provider and datacenter chosen. If you're thinking of installing BuddyBoss on a cloud instance, you likely have no idea of ​​the significant cost difference between a bare metal instance and a cloud instance with equivalent features. Bare metal instances often offer superior performance at a lower cost than their cloud counterparts, especially when considering the resource-intensive requirements of BuddyBoss.

Even for a dedicated server, it's essential to know where to buy to get the best value. It's crucial to choose ISO27001-certified and GDPR-compliant data centers to ensure security and regulatory compliance without breaking the bank. Choosing the right data center not only impacts costs, but also the reliability and security of the service.

Our experience, gained since 2005, has allowed us to tackle numerous professional challenges in the Linux hosting and systems industry. Thanks to this extensive experience, we are able to select the best data center and server-side hardware technologies for your needs, ensuring high performance and security at an affordable cost. As independent vendors, we can compare quotes and choose the best solutions, avoiding unnecessary surcharges and ensuring your hardware investment is maximized.

Server-side tuning and optimization.

A well-configured server-side software stack is crucial to ensuring the best performance from BuddyBoss. Choosing the right software and configuring it optimally can make the difference between an average-performance site and an exceptionally fast and stable one. For example, there's a significant difference between installing a standard stack with NGINX, PHP-FPM, MariaDB, and Varnish and configuring the same stack with in-depth 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 extensive experience in server-side tuning, particularly with the InnoDB and AriaDB engines used by DBMSs such as Percona Server or MariaDB. These database engines, when properly configured, can offer significantly improved performance, reducing response times and improving transaction management capacity. Our experience allows us to optimize these components to maximize available hardware resources, improving the speed and overall stability of the system.

Application Profiling with New Relic (or any other APM)

BuddyBoss application optimization requires a thorough approach to identify and resolve performance bottlenecks. One of the most effective techniques for achieving this goal is application profiling using Application Performance Management (APM) tools like New Relic. New Relic, and other similar APMs, provide 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 visualize how each system component responds. This tool provides crucial insights into server, database, and application code performance, highlighting areas requiring improvement. For example, New Relic can help identify slow SQL queries, inefficient PHP functions, or third-party components negatively impacting response times.

For BuddyBoss, where every request from logged-in users must be dynamically processed, the use of APM is essential. New Relic allows you to identify database queries that cause slowdowns, monitor AJAX calls, and understand which parts of the code are consuming 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 user profile page load times in BuddyBoss. Through profiling with New Relic, you might discover that a particular SQL query is taking 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.