[wp-hackers] Dealing with WP cron's raciness (Otto)

[David Anderson]

> If you're expecting more than 1 hit per second on a normal basis, and
> it's a problem for your particular setup, then you'd probably be
> better served setting DISABLE_WP_CRON and creating a real cron job to
> call it every so often instead. It doesn't even have to be a wget to
> the URL, you can run it with a direct "php wp-cron.php" command just
> fine, for non-multisite instances.
Hi Otto,

Thanks for the feedback and info.

My motivation in trying to torture-test the cron system is that, as 
Brian guessed, I'm trying to get the best solution I can for generalsied 
worst-case scenarios. It's for UpdraftPlus 
(http://wordpress.org/plugins/updraftplus). My estimation based on the 
download stats from that page is that there are approx 5,000 or more new 
users installing it every week. Every couple of weeks or so, I get a 
support request from somebody whose backup runs multiple times, despite 
the existing checks in the WP cron system. From my research, they're all 
over-loaded. Some are hitting wp-cron.php directly because their web 
hosting company requires them to do that (I know, that's non-optimal, 
but that's how it is). Hitting this issue once for 10,000 new users is 
not bad, but I'd much rather have it never - even 1 in 10,000 adds up to 
26 times a year. My support philosophy is to try to drive support 
requests as close to absolute zero as possible, and spend the time 
writing new code instead!

Anyway - for anyone else interested, or coming across this later, I'm 
using a modified version of Alex King's code from WP_Social - the only 
modifications are to fit my own logging system, and some slight 
generalisation to allow for locks with different names. The code is 
already in the SVN trunk for UpdraftPlus. Alex's approach works pretty 
much out-of-the-box for me; for the general case, though, it needs a 
little sleep()-ing to enforce a minimum period that the semaphore lock 
can be held for, as if it's dropped too quickly then you can get 
multiple runs again (albeit fewer of them than without using the 
semaphore lock at all).

Final question: since the semaphore approach that Alex is using appears 
to work better than WP's existing locking mechanism, do you think 
there's a case for me to work Alex's code into a core patch, and submit 
it? Would it likely to be accepted, or would I be wasting my time? I 
know that Alex said that WP has an "at least once" model, but reading 
the code, and seeing that it's *trying* to apply a lock, my 
interpretation of that was "it doesn't work as well as it could, so the 
model got re-branded"... ? i.e. the model is really "we wish it only ran 
once, and we try, but we can't guarantee it", and if the semaphore 
approach could improve the situation, then it'd be welcomed into core?

Many thanks to all who've helped,
David