We recently released our biggest Performance Update yet for the BuddyBoss Platform, version 1.9. This performance-focused update was the culmination of months of work from our product team and addresses several major areas of the platform that needed to be whipped into shape!
While the beta was getting it’s final paint job we tasked our product team with putting the release through its paces to see just how well it was running…
And the results are pretty amazing!
In this post I’m going to walk you through each of the major areas we addressed, pull back the curtain on the work that we did and show you the results that we’ve managed to achieve after taking it out for a spin.
Start your engines!
What We Improved
Our v1.9 Platform update focused on improvements in two major areas with several key enhancements in each.
Optimized Database Requests
Every time someone loads a page on your website, or interacts with a feature, your server has to go and think about what it needs to do; go and find some information or store some new information in the database to fetch again later. Each of these actions; searches, reads or writes, is a “database query”.
On a static website these queries can be easily diminished through some simple caching, but on a dynamic platform like BuddyBoss these queries are much more complex, happen much more often and in much greater numbers. That means your server has to work harder.
In 1.9 we refactored several key functions and loops to reduce the number of queries needed and remove any unnecessary ones to ensure pages and sections were loading efficiently. Overall this results in faster pages and interactions but more importantly a significant decrease in server load.
To make use of these improvements there is nothing you need to do – other than install the update – the queries take care of themselves!
Enhanced Object Cache Support
The different types of caching can be a little complicated to understand but to put it simply – “object” caching helps your server remember the answers to the questions you ask, so the next time you ask a similar question it has most of the answer already prepared for you, where “page” caching helps you serve an identical copy of the same thing over and over again with no changes.
Page caching is very common for static websites where the content on each page doesn’t change frequently, but isn’t really appropriate for a community platform with dynamic content, where each page loads something slightly different for each user. That means BuddyBoss needs to rely more on object caching. The more areas of the BuddyBoss platform that support object caching the fewer server resources are required to do the same job or on the flip side – the more jobs the server can handle with the same resources.
In this update we significantly enhanced the extent to which the platform makes use of object caching, which works in tandem with optimizing database queries, to serve requests in a much more efficient way across all components. This also significantly reduces server load allowing you to serve more requests, faster and at the same time providing a better experience to more of your users, without upgrading your hosting.
BuddyBoss, like WordPress itself, supports two types of object caching; Memcached and Redis. These are two different object caching standards you could choose from but without getting into too much detail on the differences in this video, we recommend Redis for the best performance gains. If you already have Memcached configured and working on your server, that will work too.
In order to take advantage of these improvements (and believe me, when you see the results, you will want to) you need to make sure your server supports object caching and has Redis or Memcached object caching installed and enabled, your hosting support can help you verify this. If using Redis, as we did in our testing, you will need to install and activate an Object Caching plugin on your site; we recommend Redis Object Cache (And it’s free!)
Performance Testing
We ran a series of tests across the key areas of the platform to compare this version to the previous public release and evaluate just how impactful this update was.
Test Environment
For this first phase of testing we wanted to get a sense of how well our performance improvements would impact the user of a mid-sized community, on a decent server in a reasonable price band with a pretty typical setup. So we decided to test using:
- AWS 8vCPU 16GB RAM (C5 instance, Gp2 drive type)
- Apache webserver, PHP 7.4, Mariadb 10, no server side caching (other than Redis)
- WordPress v5.8.3
- BuddyBoss Platform v1.8.7 vs v1.9 (the Beta Performance Version) with no additional plugins installed other than BuddyBoss Platform, App Plugin & Theme.
We configured the server in a typical way that a consumer with an intermediate level of knowledge would be comfortable with, without any of the special optimisations or enhancements that a more advanced user might consider.
However, it’s important to note that the specifics of the test environment are not particularly relevant for this phase; we are not testing how well this server performs against another server, or how to get the best performance from this server. What really matters is the relative difference between two versions of the platform hosted on the same environment.
Test Database
In order to simulate a real world BuddyBoss database to test against we didn’t want to just use our demo content. Instead we gathered some metrics from one of our agency customers and then created a dummy database that replicated the size and number of all of the resources that their real-life website was operating with.
Our test database consisted of approximately:
- 55,000 members
- 75,000 activity posts
- 20,000 WordPress posts
- 210 groups
- 50 suspended and 90 blocked members
- 35,000 records for cached APIs
- 85,000 notifications
Areas Tested
We ran our tests on 20-30 different areas of the platform each, depending on the test, focusing first on the most trafficked areas of the platform and then selectively testing some key areas specific to the work we had done including:
- All key directory pages – including Activity, Members, Groups, Photos, Videos, Documents, Forums…
- Group pages – including Group Activity, Group Photos, Group Messages…
- Key single pages – including Single Activity, Single Forum Topic.
As well as several other key pages.
We also tested certain interactive features particularly those relying on Ajax such as:
- Global Search
- Searching members directory
- Search @mention
- Post an activity post
- Sending a single message
- Sending a message to 5,000 people from a group
Data Gathered
We wanted to test both perceived performance improvements but also resource usage improvements, so for the results we wanted to gather we decided on:
- Page Load Time
This is the most obvious choice for perceived performance improvement; how long does it take each page to load for a user. When a page first loads on BuddyBoss it generates the static HTML elements and then loads the dynamic content using AJAX. You will recognise this as the “Please wait…” message or spinner you see when something is loading.
For our page speed tests we isolated the dynamic content areas (AJAX) to give a more relevant comparison between the different areas of the platform that have been optimized.
- Database Requests Per Page
The percentage improvement of database requests called on each page, where fewer requests means a lighter load on the server.
- Server Load Tests
The number of total requests of a single resource the server was capable of executing in 30 seconds at its maximum capacity. This shows how much more work the server is capable of achieving with the same resources because it is now working more efficiently.
- API Requests
Specifically to focus on how this performance improvement impacts the BuddyBoss App, we also ran the above tests in an environment simulating how the App communicates with the server directly via the API
- Concurrent Users
For the above tests, where appropriate, what was the impact when the same requests were made by 20 concurrent users and 100 concurrent users, to get an indication of how this performance improvement behaves as it begins to scale up.
- Redis Caching Enabled & Disabled
Finally, how did all of the above compare when redis object caching was enabled and disabled to demonstrate the percentage improvement that was gained by our increased support for object caching.
Test Results Achieved
Now that we’ve covered our test methodology and detailed our environment and test cases that we ran, let’s take a look at the results that we were able to achieve.
Page Load Time
Page load time is the result that will be most immediately experienced by your end users. This update pushes this perceived load time down by over 15% on average with more than half of the tested pages achieving above a 10% faster load time. The results shown are the average improvement to fully load the AJAX dynamic content.
Highlights
- Directory Pages Average 13% Faster
The directory pages are typically the most trafficked pages on your site, this includes the Activity Feed, Members, Groups, Photos, Videos, Documents & Forums directories. Overall the directory pages are now 13% faster to load on average, with the Photos directory clocking in at over 26% faster and the Documents directory reaching over 33% faster to load.
2. Group Pages Up To 27% Faster
Group pages get a big uplift, achieving over 20% faster loads on average. Group Photos saw the biggest improvement, coming in at almost 27% faster, with the Group Activity seeing an improvement of almost 25%
3. Group Messages Up To 75% Faster
One of the best results across all our tests came from an enormous improvement to Group Messages load time, where a group message thread with 5,000 members loaded 75% faster on our new version.
Database Requests Per Page
This performance update achieved an average of almost 50% fewer database requests across the key platform pages, with some areas improving by up to 88% with caching enabled compared to the previous version. That really is an enormous improvement and will immediately have an impact on all platform users regardless of the size or configuration of your server.
There were significant improvements across the board but let’s take a look at some of the highlights:
Highlights
- Forums Average 82% Fewer Database Calls
The greatest overall improvement came across the major areas of forums, with an average of 82% fewer database calls with caching enabled across the forum directory, single, topic and discussion pages. The Single Forum and Forum Topics pages achieved an incredible 88% improvement each. Even without any caching, Forum pages are running 21-25% fewer database queries which is a big improvement.
- Directories 58% More Efficient
On average the directory pages are loading 58% fewer queries when cached, with the Activity feed itself loading 55% fewer. Groups, Photos & Documents have seen over 60% improvements each. This will really impact the overall experience of your platform to your users.
- Group Pages Improve 25% On Average
Group pages also benefited significantly from this update overall achieving an average of 25% fewer queries each when cached, across Group directory pages, Activity & Photos when tested with 5,000 group members and all of their content.
Server Load Tests
We tested the maximum number of page requests and AJAX requests the server was capable of executing in 30 seconds by 20 concurrent users and 100 concurrent users. Page tests showed between 3-4% improvement on average but AJAX is where this update really shined with an average of 21% improvement across all tests and 32% average improvement for all tests at 100 concurrent users.
Highlights
- Single Activity 181% Improved
The area with the most significant improvement demonstrated here was the activity feeds and posts with up to 11% improvement in page requests of the activity directory but for AJAX requests the performance almost doubled; with 97% more requests of the feed executed with 100 concurrent users. The single activity post AJAX was capable of nearly triple the performance with 181% more requests in 30 seconds with 100 concurrent users.
- Network Search Up To 38% More Efficient
Network search also had a big improvement evident in these tests with the server capable of loading 15% more page requests at 20 concurrent users and 38% more at 100 concurrent users. AJAX requests for Network Search were almost 10% greater at 20 and 22% greater at 100 concurrent users.
- Groups AJAX Up To 20% Improved
Groups pages also had a great improvement overall with page requests up a few percent for 20 and 100 concurrent users, but group AJAX really had a lift with the Groups Directory seeing an 18.5% average improvement and the Groups Activity loading 20% more requests on average across 20 and 100 concurrent users.
API Requests
API Request tests help us highlight how BuddyBoss App customers are specifically impacted by this performance update, as most of the app content is generated through API requests. On average the single API request time was improved by more than 14% across all tests with the average number of requests increasing by almost 16%.
Highlights
- 50% Improvement Of Activity Feed API
The single request time of the Activity Feed API improved by over 23% and the total number of requests the server was capable of increased by an incredible 50%.
- Members API Request Improved 34%
The members API also enjoyed a significant improvement with single API requests 26% quicker and the server capable of achieving 34% more requests than before.
- Documents, Videos & Photos API 13% Improved
The documents, videos and photos APIs also had a decent improvement of 13% quicker on average with the documents API request time down almost 15% and the total number of requests increased by almost 21%.
Redis Object Caching
For many of the tests I’ve mentioned already I gave you two sets of results; cached and uncached. Because we were load testing the maximum capacity of the server we are looking for a decrease in the single request time and an increase in the number of requests the environment was capable of when comparing the old platform version to the new one – demonstrating it is performing more efficiently overall.
But in order to understand how much of an impact caching is having compared to just improvements in the queries themselves, we can compare two identical tests on the new update with caching disabled and enabled. The difference between their performance results shows us how much more performance we can squeeze out through the use of Object Caching.
Highlights
- 35% Reduction In Database Queries
Across all database tests Redis Object Caching was responsible for an average reduction of 35% in database requests compared to the same test run with caching disabled. The Groups directory, forums and the single forum page had a 60% decrease in requests thanks to object caching.
- 11.5% Increase In Server Request Capacity
Across all areas we tested there was an average increase of 11.5% in the number of requests the server was capable of when object caching was enabled when tested with 20, 100 and 200 concurrent users. That means you can squeeze an extra 11% out of your current server environment just by updating to this latest version and using Redis! At 200 concurrent users the update resulted in over 17% greater capacity through the use of object caching.
Future Performance Updates & Testing
Both the improvements released in this update as well as the work undertaken to test the results were significant internal projects that we will continue working on over the months and years to come.
Performance improvements are constantly being identified and prioritized alongside our feature enhancements and updates by our product team. Any new features or enhancements are always built with performance at the forefront, but this project represents a significant improvement to some of the major areas of the Platform.
One of the biggest undertakings of the performance testing project was actually in the development of the test environments and testing tools capable of delivering the results we needed. Now that we have performed this first phase of work we will find it even easier in future to test specific areas of the platform to identify what we can optimize next!
I’m sure you’ll agree the results we’ve managed to achieve here are pretty great and we’re excited to see you test this update out on your own and leave a comment below to let us know what you think.
-
Article
- Inside BuddyBoss
