-
Notifications
You must be signed in to change notification settings - Fork 200
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Performance improvements for checking schedule intervals #276
Conversation
Hello, this looks excellent. Give me time to fully wake up and integrate that. Thanks! |
I approve of this change. |
May I get a Square sticker? |
@drcapulet What if I introduce a scheduler option to tell it not to check the frequency at all (trusting you the user to feed it with schedules that match)? |
Is using Thanks in advance. |
@jmettraux Ah yeah - looks great, thanks! |
When working with large schedules of jobs (~100) that run infrequently (weekly or less) our Sidekiq server can take 8 to 10 minutes to start due to the check to ensure jobs don't run more frequently than the scheduler.
For Cron jobs, Fugit supports up to 1 second cron resolution, the entire check is skipped if the scheduler frequency is below that. Then based on a simple heuristic if the minimum delta between the 2nd, 3rd, and 4th runtimes is greater than a week the brute_frequency method is used. Otherwise the old enumeration logic over next_time_from is used.
I added simple specs to ensure adding both frequent and infrequent cron additions take less than a second (on master the infrequent spec takes 12 seconds).
This reduces the schedule parsing time for us to just under 20s.