1. b2evolution CMS User Manual
  2. Operations Reference
  3. Performance
  4. Performance Optimization

Performance Optimization

There are several things you can do to optimize the performance of your system.

Using Fast Web Hosting

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.

Disabling Plugins you don’t need

Plugins are designed to execute only when they are needed. However, many plugins will still load a .js and/or .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 Content Delivery Networks (CDNs)

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.

Eliminating Long Running SQL Queries

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 ).

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.

Putting Caching Mechanisms to Work

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.

Not abusing Widgets

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.

Extreme Situations

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)

Apache Tuning

Some apache tuning is possible through your .htaccess file, however, for the most part you will need a VPS or a dedicated server to be able to most efficiently tune your apache/webserver.

mod_deflate

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!

mod_expires

Enabling mod_expires will force apache to send Expires: headers, especially for all the static files (CSS, images, javascript, etc…). This will make no difference the first time a visitor visits your site, but on subsequent accesses, it can make a dramatic difference!

Without an 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.

With the 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:

 <IfModule mod_expires.c>
        ExpiresActive On
        ExpiresByType application/javascript "access plus 1 week"
        ExpiresByType text/css        "access plus 1 month"
        ExpiresByType image/gif       "access plus 1 month"
        ExpiresByType image/png       "access plus 1 month"
        ExpiresByType image/jpeg      "access plus 1 month"
 
        # Now we have Expires: headers, ETags are unecessary and only slow things down:
        FileETag None
 </IfModule>

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).

More Apache tuning

Here are interesting resources about Apache tuning for PHP:

Created by • Last edit by on 2020-01-08 22:56 • •

No feedback yet