Skip to content
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

Ideas to improve the processing of background jobs #200

Open
davidor opened this issue Apr 21, 2020 · 1 comment
Open

Ideas to improve the processing of background jobs #200

davidor opened this issue Apr 21, 2020 · 1 comment

Comments

@davidor
Copy link
Contributor

davidor commented Apr 21, 2020

These are some ideas that we have discussed in the past to improve the processing of background jobs:

  • Evaluate Sidekiq as a replacement for Resque.
  • Implement a way to process at least a small % of non-priority jobs even when there are priority jobs pending.
  • Break up big report jobs into smaller ones.
  • Improve the way we reschedule failed jobs to avoid growing queues under stress load. The problem with this is that when an incident happens, the queues start growing, and the priority one in particular grows very fast. Shoving more jobs on top of a growing queue is not a good idea, as the system clearly can't cope with the workload
@andrewdavidmackenzie
Copy link
Member

I'd be interested to see a split of time taken:

  • Listeners: required processing / time to create and enqueue jobs
  • Workers: time to dequeue jobs / required processing

to see just how far we are from the crossover point where:

  • Workers required processing time < Listeners enqueue time

and we could scrap the whole background processing split, queues, sidekiq/rescue, priorities and all that goes with it...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants