Function Cache

Description

See installation.

Installation

Just activate it. Once you do this, you’ll have access in your plugins/functions.php file/templates to use the core cache functions provided.

How do you use this then? Say you have a function that takes the server a long timer to load (say a half second). Say your function looks like this.

function get_rooms($category) { //database intensive queries return $output; }

Wouldn’t it be nice if you could just use a cache for get_rooms? Here is how using the new functions you get with the plugin:

function get_rooms($category) {

/** Cache check **/ $cache_query = __FUNCTION__.serialize(func_get_args()); //really you can use anything for the query though $cache_value = function_cache::check_if_in_cache($cache_query); if ($cache_value) {return $cache_value;} /** End cache check **/ 

//database intensive queries

/** Cache Load - Add output to cache with expiration triggers **/ $expiration_triggers = array(     "post_types" => array("room","suite"),     "post_ids" => array() );  
function_cache::load_into_cache($cache_query,$o,$expiration_triggers); /** End Load Cache - Value now added to the cache database **/ 

return $output; }

For large sites, using function_cache::check_if_in_cache and function_cache::load_into_cache will improve performance dramatically. The key here are the expiration triggers.

When you use function_cache::load_into_cache it require three parameters. A name, value and expiration triggers. The name can be whatever, but should be distinct (say “Suites”). The value would typically be the html you want to store in an output buffer. Then the expiration triggers are an array of conditions that when changed/deleted, will expire the corresponding cache values and no more.

Right now the options are “post_types” and “post_ids”, but hope to add more in the future. So say you want to cache the contents of a page. An easy way to do this is with the ID (get_the_ID()). So you might use:

$expiration_triggers = array(     "post_types" => array(),     "post_ids" => array(get_the_ID()) );  
function_cache::load_into_cache($cache_query,$o,$expiration_triggers); 

This also works great for custom post types. Say you have a custom post type rooms, and if any room is modified, you want to flush all cache values associated with rooms. You could use:

$expiration_triggers = array(     "post_types" => array("rooms"),     "post_ids" => array() );  
function_cache::load_into_cache($cache_query,$o,$expiration_triggers); 

Multiple post ids or post types are accepted (hence the nested arrays).

FAQ

There are a lot of WordPress caching plugins. Why this one?

The big problem with most cache engines is they cache too much and the cache values don’t regenerate when you make updates. This solves both problems, which is frankly pretty unique for WordPress cache engines.

What about W3 Total Cache?

This is probably the most popular cache plugin out there. It can be good, but in my experience it creates a lot of stale content that frustrates users when the website doesn’t get properly updated.

What about WordPress Transients?

Couple problems. WP puts the transients in the wp_options table which causes and is inflected with serious bloat (bloat = performance issues). WordPress function cache uses its own table to improve performance. Second issue is that transients just use a date to trigger cache deletion. This is not practical and too limiting. This is why this cache engine associates page ids and post types with the cache values, and deletes name/value pairs when posts are updated.

Why is my site slow?

It is either client side or server side. To determine if it is client side, view the source of a rendered slow page. Save it as say test.html and upload it. If that is faster, you have a server side problem. If not, client side. Another way to check is in Firefox and Chrome, the loading graphic spins counter clockwise for server load and clockwise for client load (rough abstraction). If it spins say more then a half cycle “6 hours” counter clock-wise, this plugin may help.

What slows down a wordpress page from the server side?

Much of what is on a wordpress template is innocent (including get_content()). Usually the culprits are components that use the wp_options and wp_posts table and components that incorporate looping. 95% of slow WP sites is due to slow databases. WordPress stuffs so much in the wp_options and wp_posts table and then multiplies these together which takes a ton of computing power. Key is to minimize the lookups you need to do to the database. This mostly means caching the functions that contain important query loops and custom field lookups.

How do I find what specific component on my template is slowing everything down?

You could do a series of AB testing, disabling core functions to isolate the culprit. I do highly suggest the plugin “Query Monitor” which can actually do a very good job of isolating what is slowing down a page.

How does this relate to Custom Post Types & Fields?

These tend to be the biggest resource hogs. If you use Advanced Custom Fields, this is especially bad because they multiply the wp_options table on itself (which becomes a serious issue for big sites). ACF also uses wildcard strings for their repeater fields which turns into a performance nightmare for queries. Custom Content Manager is much faster (20X by my benchmark for their get custom field function) and benefits from a built in cache unlike ACF. But CCTM doesn’t cache results across sessions. WordPress Function Cache does.

Can upgrading Apache/PHP/MySQL help with my slow website?

Yes, but usually not significantly. WordPress performance tends to degrade in an exponential fashion whereas these improvements just improve things in an incremental fashion. Same with hardware. The best updates you can do would be to switch tables to Innodb, make sure you are using the latest MySQL, optimize MySQL for large table queries, and install OPcache (for PHP 5.5). OPcache is AWESOME! But even with that you’ll still need a plugin like this one to handle sites with large databases.

Reviews

Contributors & Developers

Changelog

20150122

The very first version of the program!