Caching and Cache Levels
b2evolution has several levels of caching. Some are active by default. Some need to be manually enabled or configured for best performance.
PHP is a script language. By default, every time a .php file is accessed, the script is reparsed & recompiled into a form of executable code called opcode. This is done over and over again at each page load which is not very efficient.
An opcode cache is a PHP extension that will cache the opcode version of the PHP scripts in shared memory so that each subsequent call to the same PHP files doesn’t require reparsing & recompiling.
We recommend APC with PHP5 today because it’s anticipated to be directly integrated into PHP 6 in the future.
Every time a SELECT query is sent to the MySQL Database, MySQL can cache the results in memory. If subsequent identical SELECT queries are made, and the data hasn’t change, the data can be retrieved directly from the memory cache without requiring complex operations.
On a typical MySQL installation the query cache is enabled by default and does not need special configuration.
At every page request, b2evolution loads objects from the database. Such objects can be a User (user details), a Blog (blog params), a File (file details), etc.
b2evolution uses objects such as $UserCache, $BlogCache, $FileCache, etc. in order to cache the objects that have already been requested within the current request.
With this system, b2evolution only needs to load a given User once, even if the same User has authored 5 posts on a single page and the first & last name of that user need to be displayed 5 times on the same page.
There used to be an advanced configuration switch to disable those DataObjectCache objects but there was no reason to ever disable those.
b2evolution can automatically resize images to different sizes. Image manipulation is a heavy process that should not need to be repeated until the original image changes.
Thus b2evolution will create a folder named .evocache in every subdirectory of the media folder where it encounters an image that needs to be resized. Each .evocache folder can contain several different thumbnail sizes.
Note: thumbnails is a generic term. They can actually be of any size, including very large like 800x600 pixels.
Note: because they start with a dot, .evocache folders are hidden folders. This is so the media hierarchy can be browsed without interference.
When a file is deleted through the b2evolution file manager, the corresponding cached thumbnails are deleted at the same time.
When you edit a post, comment or message (let’s call them Items) in b2evolution and validate your edits, a number of rendering plugins may be applied. If you have complex rendering plugins, this operation may take significant time. Thus, b2evolution caches the result of the rendering for each item until the item is modified again. When a blog is being browsed, the items contents displayed come directly from the cache without the need to re-render each one of them.
Note: Rendering plugins have an option to do part of the rendering in real time at display time but this is generally not recommended.
The pre-rendered items are stored in the following tables of the database:
b2evolution has several levels of high level caches:
The output of widgets can be cached in memory. (b2evolution v4+)
This requires APC cache to be installed at the moment.
This needs to be enabled in the General Settings.
Work in progress at the moment…
b2evolution can cache complete web pages for 15 minutes. This is especially useful for situations where some pages have made it to the front page of social news sites like Digg, Slashdot, Reddit, StumbleUpon, etc.
In this case, the page only needs to be generated once every 15 minutes and the rest of the time the cache is served almost instantaneously.
The "15 minutes" duration can be controlled with
$pagecache_max_age configuration variable.
Note: hits are still being recorded for stats. This makes this an interesting alternative to adding a front end reverse proxy with caching.
Note: Page caching is only used for anonymous users in order to make sure that no private data is ever saved in the page-cache and then served to a different user. This means that you will not directly benefit from page cache acceleration when you are logged in (front-office and back-office) (You may still benefit from the reduced server load though).
The cached pages are saved on disk in a folder called
/_cache at the root of the blog ($basepath).
This feature must be enabled on a per-collection basis (Collection settings). There is also a Global cache that can be enabled in the Global Settings for all pages that are not specific to a given collection.
It is well known that web browsers cache content locally. There is work in progress to have better cache control of what is being cached in the browser and for how long.
For additional ways of improving performance of your site, please see optimization.
Created by • Last edit by on Oct 23, 2016