ClassicPress is a hard-fork of Wordpress 4.9 and has the same functionality as that version of WordPress although version 2 of ClassicPress is on the way, which is where changes will start to be introduced.
Some of my sites have been experiencing a growing number of visitors to the point where it is starting to cause problems. The reason for the problems is that the built-in ClassicPress cron handler (WP-Cron) is not a real cron job, but a mimic. And an inefficient one at that.
On high traffic sites this cron-mimic can cause performance problems. A normal system cron job will run continuously and trigger at the scheduled times, but WP-Cron does not run continuously. Instead, it fires on every page load which is where the performance problems can come in; if there are not sufficient PHP workers for the requested processes, a request will be initiated and wait until the next worker comes available. There is also an issue on low traffic sites that a scheduled task won’t start until a page is loaded.
It is recommended that the WP-Cron job be disabled and a system job created and run on a pre-defined schedule.
Disabling WP-Cron is easy to do; edit your wp-config.php file and add the following code above the /* That's all, stop editing! Happy blogging. */ line:
/** Disable cron. */
define('DISABLE_WP_CRON', 'true');
You then need to create the system cron job; the format of this may vary depending on your host. This is the one which works for my host:
cd ${HOME}/public_html; /usr/local/bin/php -q wp-cron.php
Two possible variations are:
cd /home/{username}/public_html; php -q wp-cron.php
php -q /home/{username}/public_html/wp-cron.php
For my main sites I have set the cron to once every hour, but on less trafficked sites I’ve opted for once or twice a day or week.
This post is part of the series on Implementing Fastpath's Audit Trail and is part of the parent Implementing Fastpath's Assure Suite series.
