Minimum gap between cron firings, and the reason cron can default to on.
WITHOUT IT THE BUDGET IS NOT A BUDGET. The alarm is not a clock -- it re-arms at +1 ms while a
fill queue is draining -- so "once per alarm" during an active fill is once per page, each one
costing an interpreter unit and up to maxRows writes. The per-firing budget bounds a firing; it
says nothing about how many firings there are, and rows written is the meter that binds
regeneration.
15 minutes puts the worst case at 96 firings/day, so even a site that hit maxRows every single
time spends 48,000 of the 100,000 daily rows -- and a quiet ring writes nothing at all. Drupal's
own automated_cron default is 3 hours, which is far too coarse for Scheduler.
Minimum gap between cron firings, and the reason cron can default to on.
WITHOUT IT THE BUDGET IS NOT A BUDGET. The alarm is not a clock -- it re-arms at +1 ms while a fill queue is draining -- so "once per alarm" during an active fill is once per page, each one costing an interpreter unit and up to
maxRowswrites. The per-firing budget bounds a firing; it says nothing about how many firings there are, and rows written is the meter that binds regeneration.15 minutes puts the worst case at 96 firings/day, so even a site that hit
maxRowsevery single time spends 48,000 of the 100,000 daily rows -- and a quiet ring writes nothing at all. Drupal's ownautomated_crondefault is 3 hours, which is far too coarse for Scheduler.