There are several things you can do to optimize the performance of your system.
First off, obviously, you may need a fast web host (we have 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.
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. It is useful to use 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.
While some plugins are actually designed to improve performance through various tricks, some other plugins are programmed without any consideration given to performance. Do a test deactivating all your plugins and see if it makes a difference.
Even built-in widgets can hinder performance if you use too many in your sidebar for example. This can usually be resolved by enabling block caching though.
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 Aug 03, 2018