There are several things you can do to optimize the performance of your system.
First off, obviously, you may need a fast b2evolution test sites for several hosts; you can compare the speed to your current host). No matter what a host using SSD drives will definitely make a difference.
Plugins are designed to execute only when they are needed. However, many plugins will still load a
.css on every page, even when they are not used on that page. Demanding better plugins to their author is one solution. Another is to make sure you disable all the plugins you don’t need.
For the plugins you do need, test with the plugin enabled and the plugin disabled. If you notice a significant difference, that plugin may be coded in a poor way (which is not uncommon with third party plugins, no matter which CMS you use).
Using CDNs is generally an easy and quick gain on all the transfer times of your JS, CSS and image files, which make up for 90%+ of your transfer times due to network latency. Learn more.
Some SQL queries create more stress on the system than others. Although b2evolution is optimized for a wide range of scenarios, your particular usage context may generate such long running queries. It is useful to have a mechanism to detect them (for example New Relic).
On several b2evolution versions prior to 5.1 (when this feature was removed), one common heavy query is the Smart Views Counting. If you have performance problems, try to disable this feature.
Once you have a reasonably fast web host, a good CDN, and no SQL bottlenecks, the one single biggest performance enhancing technology is caching.
b2evolution can leverage several different caching mechanisms. Some are enabled by default, some need manual activation or installation.
Please refer to the Caching and Cache Levels section for more information on all these caches.
Depending on their settings, some widget may not be able to be cached.
Also, some widgets have settings that make them execute faster/slower or generate more/less code.
Keep an eye on which settings you use for your widgets.
We do not recommend this, but if you’re trying to squeeze a heavy loaded b2evolution onto a tight shared hosting account, you may try the following to mitigate situations where your hosting provider says you’re using too many resources:
- Disable Hit Logging, including for public pages
- Disable AJAX Forms, so they don’t generate extra requests to your site (you may get more spam though)
On apache2, make sure you enable mod_deflate so that the HTML being sent back to the requesting browser is as small as possible.
This is the second most significant performance improvement you can get after enabling caching.
mod_deflate can divide the amount of data being sent by 3 to 5! Even on high bandwidth internet connections, the difference between sending 20 and 5 Kilo Bytes of data can be significant! This is because it’s not only about bandwidth but also about latency times and TCP slow start. Small files can really go through exponentially faster!
Enabling mod_expires will force apache to send
Expires: header, the minimum that will happen is that the browser will send a request to see if the file has been modified since it last got it. It may receive a "304 Not Modified", but due to network latency, that still takes time you can feel, especially on mobile or transcontinental connections.
Expires: header, the browser will not try to ask if the file has changed until it expires. (Unless, of course, somebody hits Refresh!)
Once the module is enabled, you still need to configure it. This can be done in
.htaccess if you don’t have access to
apache2.conf. We suggest something like this:
Be careful not to enable
Expires: for text/html if you don’t know exactly what you are doing. Doing this may lead a user to seeing data cached from a previous user when different users share a browser (or when logging in / logging out).
Here are interesting resources about Apache tuning for PHP:
Created by • Last edit by on Jan 08, 2020