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.

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 active. Un-cached stats may take up to 15 seconds to load, instead. Post stats caching is active by default, and its status can be tweaked in Options > Miscellanea > Performance.

The standard mechanisms cache stats details for each post, but the stats table is actually rebuilt every time the stats page is loaded. This means that database queries and data processing are minimized, but some processing and the HTML formatting is still redone every time. 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.

Stats snapshots

The snapshot system is not based on memcached, and is not automatic. Instead, it is file-based, and relies on WP-CLI, and has been available since Post Pay Counter v2.755 (November 2019). It received significant improvement in v2.770 (January 2023).

The relevant command is wp ppc stats, which can be used to generate a given stats view (and store it, if so wished). It accepts several arguments, and its manual can be retrieved with wp help ppc stats. Some examples of usage can be found in the next section; however, the option --cache-full needs to always be appended if you want the result to be cached. Snapshot files 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 (an automatic script based on the creation date is a good idea).

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, or the snapshot will not be loaded when visiting the stats page.

By default, the stats page will take data from a snapshot, if one with a matching time range is found. It also needs to match the user’s permissions: for example, a stats snapshot created by admin, who has permission to see special settings for users, will not be served to regular users. To force fresh stats to be displayed even if a snapshot is available, use the GET parameter no-cache.

On large sites, where stats generation fails with timeout, it is a good idea to have a cron job generate stats snapshots for the upcoming day.

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

You may want to run your custom cache process after the regular Google Analytics data update is complete. Here is a sketch of a cron script you can schedule to run after the GA update happens every day. Paths may of course 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