Post Pay Counter caching features

Post Pay Counter supports caching and is compatible with WordPress caching plugins.
Post Pay Counter mostly implements caching for post stats, plugin settings, user settings and active payment criteria.

Since Post Pay Counter version 2.716 (May 2017), server side caching improves stats performance significantly.

On our tests, with several payment criteria active (words, visits, Facebook shares, comments), we manage to load around 10k posts in under 5 seconds on an average VPS with memcached. Un-cached stats may take up to 15 seconds to show up though, so the performance boost is clear. Post stats caching is active by default, and its status can be tweaked in the Miscellanea >  Performance section.

---

The standard caching caches stats details for each post, but actually rebuilds the stats table for every visit. Websites with massive amounts of data to handle may want to also cache the whole stats page for a given view. In other words, they may take a snapshot of a particular stats page that takes long to load, and then serve it quickly multiple times after.

This system is not based on memcached anymore, and is not automatic. Instead, it is file-based, and requires active action to cache something, since the cached files can be big (stats for one single author with 10k posts can reach up to 50MB). The caching mechanism relies on WP-CLI, and has been available since Post Pay Counter version 2.755 (November 2019).

The command is wp ppc stats and accepts several arguments, the manual of which can be retrieved with the command wp help ppc stats. Some examples of usage can be found in the next section; however, the option `–cache-full` needs to be appended if you want the result to be cached. Cached file are stored in the `cache` directory, which gets created the first time you cache something. Notice that there is no automatic deletion of cached files! This means that you need to take active action both in their creation and in their removal (even with an automatic script based on the creation date).

Make sure that the cached time range is exactly the same as the one you would like to see stats for in the stats page.

By default, cached full stats are only displayed if the _GET parameter `cache-full` is set. This may be overcome by using the following filter, which will ensure that if a snapshot that matches the request is found, then it will be used. This is particularly useful if you want to automate stats caching.

add_filter( 'ppc_cache_full_stats_always_show', function($status) { return true; } );

Examples

1. Cache the default stats page:
   `wp ppc stats –cache-full`
2. Cache the general view (i.e. all authors) of the stats page since the very beginning of time:
   `wp ppc stats –cache-full –time-start=1970-01-01`
3. Cache the detailed view for author ID 1:
   `wp ppc stats –cache-full –author=1`
4. Cache the detailed view for author ID 1 as seen by author ID 1:
   `wp ppc stats –cache-full –author=1 –as-user=1`

Cache after Analytics update is complete

One thing you may want to do is to run your custom cache process after Google Analytics data update is complete. Here is a sketch of a script you can schedule to run (with cron) after the GA update happens every day. Of course paths may need adjusting!

#!/bin/bash

GA_DIR=/var/www/html/wordpress/wp-content/plugins/post-pay-counter-pro/temp/ga/

while true; do
	if [ ! "$(ls -A $GA_DIR)" ]; then
		printf "No GA temp files found --> Update has finished\n\n";

		cd /var/www/html/wordpress;
		rm -f /var/www/html/wordpress/wp-content/plugins/post-pay-counter/cache/*

		## Cache commands section
		/usr/local/bin/wp --path=/var/www/html/wordpress/ ppc stats --as-user=1 --time-start=1970-01-01
		## End

		exit 0;
	fi

	echo "GA temp files found --> Retrying in one minute...";
	sleep 60; #check again in 1 minute
done