Summary:
To prevent performance bottlenecks and reduce the likelihood of CPU spikes caused by simultaneous cron executions, I propose implementing a “fuzziness” option for cron scheduling—similar to the approach used by GP-Cron.
Background & Problem:
In multi-tenant or large-scale environments, having many cron jobs fire at fixed intervals (e.g., every 5 minutes) can cause heavy resource contention, especially when those crons are aligned across sites or processes. This can lead to unpredictable performance degradation and unnecessary server load.
Proposed Solution:
Introduce a configurable "fuzziness" feature that randomizes the exact execution time of each cron within its scheduled interval. For example:
A 5-minute cron would be randomized to execute at any point between 1 second and 4 minutes 30 seconds after the previous run.
A minimum 30-second buffer is maintained around each possible cron window to avoid overlap or excessive job clustering.
This ensures that, over two intervals (10 minutes), all scheduled crons will still execute twice, maintaining timing integrity while distributing system load.
Benefits:
Reduces peak load by staggering cron executions.
Improves overall system stability and scalability.
Transparent to end users and job logic.
Especially helpful in environments with dozens or hundreds of sites or scheduled tasks.
Additional Notes:
Fuzziness configuration can be opt-in or toggled per site.
A visual or log-based indication of randomized execution could help with debugging or verification.
Thank you for considering this request!
