Update

[ukd1]

FYI, I'm working on an update of this to run periodcially, and to store the results, and to use newer versions of the gems / projects. @bensheldon if you want to help at all, there are a few things I've been thinking of doing, but tbh, not sure if worth it. Would love thoughts;

1. rather than hard-coding the setups, use the automated setups for most of the projects. i.e. install the rails g xxxx and then run rails migrate for each project when testing. Think this would make keeping up to date with the gems easier in the long run, and "fairer" incase anyone makes a mistake with the SQL.
2. auto-updating the gems; maybe this can be done by "hand" in the script though, by just bundle-updating before running. I saw you did something on this, but not sure what the downside was. Any recollection?

Some work started on my fork, fyi. It's all in main for now.

[bensheldon]

@ukd1 Thank you! I'll say I'm very, very open to any improvements/reimagining you want to make here. I am mostly using this as a test-bench for GoodJob. A few thoughts:

• I am not sure what the best Apples-to-Apples comparison is. I think this currently is testing locking/dequeuing performance. I don't think that captures the entirety of backend performance (both for queuing or entirely executing a job).
• I like your suggestion about setup. I wonder if setting it up to use ActiveJob and Rails Migrations/etc. would both be more realistic, as well as easier maintain for this project.

[ukd1]

@bensheldon I'd be down for using this as a basis for testing QueueClassic as well, and others. So, would be down for expanding what it tests and how.

AR migrations, I think are pretty realistic for how a lot of users set things up, and make life easy for this kind of testing too. Right?

Suggestion (at some point) would be forking to it's own org for testing ruby-queues; assuming it's aiming to be pretty indenpendent / fair to individual queues.

[bensheldon]

@ukd1 I just added you as a collaborator to this repo. Figured it would help you to make big changes/reorganizations in this repo if you want. Truly, I'm open.

I agree in the future it could be good to create an org too.

Technically, I haven't dug too deeply into how this repo works beyond adding and slightly tweaking individual job runner setup. I'm not sure if there are options to modernize too in terms of how it forks out workers or communicates over Redis (or how those might play with Rails).

[ukd1]

Good idea, thanks. I should have time this week to finish the changes I made this week - will make a PR before merging anyway!