Number of audit tasks generated-per-min is not configurable about glados

[pipermerriam]

I think we would get rid of the KEYS_PER_PERIOD concept and probably handle each strategy different.

• all strategies would be "throttled" by their mpsc::Channel being "full" so they would select as fast as they can and then block once their channel is full.
• random can just select as fast as possible, probably in some kind of batch size since we probably don't want to hammer the database with single row lookups.
• latest should probably get "smarter" and work backwards from the front of the chain stopping either once it hits the previous latest or some other maximum batch size.
• oldest un-audited can probably select as fast as it wants as long as it has protection from filling the queue with duplicates.

[pipermerriam]

I have an alternate suggestion that I believe gives us both of the following.

• ability to control overall audit rate
• ability to throttle each source/strategy in relation to each other (e.g. 50% towards latest, 30% towards random, 20% towards oldest-unaudited

I suggest the --concurrency flag remains to determine how many lookups should happen in parallel.

I suggest the following flags where N is a positive integer argument:

• --latest-strategy-weight=N
• --random-strategy-weight=N
• ... (etc)

We then interpret these as the respective weights for how many jobs we pull from each source.

Implementation detail: This would also imply that we give each strategy its own mpsc::Channel to enable the logic for spreading the audits across the different sources.

Each strategy can then produce audit candidates at maximum rate all of the time and will self-throttle when the channel is full.

[perama-v]

Ok that sounds good. So to check:

If there are two strategies (A weight=1, B weight=2), with KEYS_PER_PERIOD=10. Then:

• Total weight = 1 + 2 = 3
• A = 10 * 1//3 = 3 keys per period
• B = 10 * 2//3 = 7 keys per period

Or you could pass 10 and 20 for weights respectively to get 30 and 70 keys per period respectively