Performance notes

We are often asked about general performance issues when Simple:Press is installed. Hopefully, some of those questions will be answered below. But first, a quick word on our development policy.

Development policy

We spend a lot of time optimizing our code and database queries, which is usually the first and longest task of each major development cycle. We minimize calls to the database, rewrite functions, and prune code to improve performance. This is an ongoing process that continues with every release.

However, we recognize that Simple:Press Forum is a large and feature-rich plugin, and balancing performance and database activity with user requests is a constant challenge. With Simple:Press V5.0, we completely rewrote the codebase to prioritize performance, resulting in a faster and slimmer version than previous ones.

Features, features, features!

We get lots of feature requests, but can’t include them all. New features mean more code and database queries, which makes the codebase bigger.

With 5.0, we have introduced plugins for Simple:Press. This caters well for many of the old core features that were not universally used and allowed us to remove large chunks of code from the core and place them in to plugins. This means the core is much smaller and leaner and will therefore load and perform better. You only need to grab and use the plugins that you want. Many new features, unless benefiting the vast majority of the community will be added as plugins in the future.

If you want a very lightweight and bare-bones forum then the core Simple:Press can still be your choice. If, on the other hand, you want the features that some of the Simple:Press plugins have to offer then you have to accept an increase in database activity and codebase.

That’s a lot of files!

Yes – it is a lot of files. But don’t worry – they are not all loaded all of the time. Wherever possible we only load those code files that are necessary for whatever view is being displayed or operation being carried out. We have also taken great care to not load up unnecessary files and scripts in non-forum pages.

Additionally, as the Simple:Press development progresses, we are using more AJAX type operations so that data can be presented when the user wants it – not loaded in the background ready. This helps the size of the pages being loaded.

We do, currently, need to load some code even when the forum is not being displayed. This can not be helped. As a bare minimum we need to load code that checks whether the current view is a forum view and also need to load support for any template tags the user may have set up. We also ensure that any Javascript code is only loaded on forum views – both within the front-end forum and the back end administration.

And a lot of database queries!

There are a lot of misconceptions regarding the number of database queries any plugin can make. Simple:Press Forum does add a noticeable amount of new queries to your site and this is a consequence of being a feature rich plugin and also having a dynamic data requirement where database records are constantly being updated. Version 5.0 has cut down the number of queries being made substantially from prior versions.

That being said, there are two main points to make here. The first is that MySQL is a very robust database engine that can handle large numbers of queries on huge volumes of data with relative ease. A standard WordPress blog hardly scratches the surface of MySQL’s capabilities. Additionally, MySQL is very good at caching it’s data and on most installations the vast majority of data will actually be retrieved from memory – especially those queries that are repeatedly run. The bottom line is that the effect on overall performance should be marginal.

When 5.0 was rewritten, every query in Simple:Press was touched and many, many were optimized for performance.

What can I do to improve performance?

Quite a lot actually. But start by considering the following points:

• Give some thought to your hosting: Your hosting is the most important part of the equation. If you have a busy and popular site and the forum is going to be an integral part of that, overall performance starts with your host. The basic truth is that you get what you pay for. Generally speaking, the cheaper the hosting package the more you will see performance and loading issues – and not just with the forum. A web server shared amongst large numbers of websites is already a bottleneck. Choose your hosting with care and be prepared to pay more if you want more.
• Your number of forums: The more forums you define the bigger the number of database queries and returned data that needs to be processed and displayed. Defining large quantities of forums is also not really a good policy for your users either who will tend to get lost scrolling through them. Plan out your forums with care and keep them to a minimum.
• Number of topics and posts displayed: This is, of course, a trade off between smaller queries to return smaller topic/post lists and the possibility of requiring multiple pages to display them. The question is – how busy is your forum? If most topics do not spread across multiple pages keep the post list smaller.
• Consider your options: Our experience on the support forum shows that very few users take time to consider, review and plan for the options that we have made available. We get many questions repeatedly that require a simple trip to the forum options – or a small tweak to a forum template – to turn on or off a feature. Time spent looking through the options and considering what is and is not displayed before you start can be helpful to reduce both queries and rendering time. If you don’t need it – why keep it!
• What about the components and plugins: The same is true for the forum ‘components’ – essentially add ons, extensions and, of course, forum plugins. Take time to decide if you really need them. Only activate those plugins you really feel you can not do without. As a general rule it is also better to remove any plugins – both Simple:Press and WordPress plugins, that are not wanted.
• So – who can do what?: Review your User Groups and Permission Sets and ensure you have the smallest number of each defined for your purposes. And double check the permissions you are granting your guests and users. Many of those permissions, when made available, will result in extra database queries and code being included.
• Use the CSS and Plugin Caches if possible: Turn on the CSS and JavaScript caches (Options > Global Settings). If your forum fails to display properly after turning the CSS cache on then turn it off again. Most servers and hosts have no problem with the CSS cache but a small minority do not seem to behave properly.
• Using Gravatars: If you have selected to allow the use of Gravatars, remember that every time a users avatar is displayed, your server makes a call to the remote Gravatar server. This can rapidly and noticeably slow down rendering of the topic view. We strongly recommend the use of our Gravatar Cache plugin that caches gravatars locally and eliminates these remote requests.
• Using WordPress cache plugins: WP Caching plugins can help boost the overall performance of your website but they can not be used with your forum page. They can work well with a standard blog type website where the data does not change that much. But data on a forum can change from one second to the next and under these circumstances the traditional cache will not work properly. So it is important to ensure you exclude the forum page from taking part in the cache activity.