...
Parameter | Sample value | Justification/Notes |
|---|---|---|
|
| |
|
| Larger jobs should be deprioritized |
|
| |
|
| New jobs get no boost |
|
| More important than job + chunk size |
|
| 72 hours, This should probably be confirmed/updated |
|
| Jump to the top of the queue |
|
| If the tenant has no jobs running, then it should be prioritized |
|
| If the tenant is using all available workers, it should be significantly deprioritized. If no other tenants are competing, this will not matter (since all jobs would be offset by this) |
|
| Very small; we only want to order parts amongst others within a job (which would likely have the same score otherwise) |
|
| The last chunk will likely have a higher score due to the chunk size metric. |
SCORE_PART_NUMBER_LAST_REFERENCE | 100 | Does not really matter due to small range |
Implementation notes
Want to disregard a metric?
To disregard/ignore a metric, simply set its parameters to zero. For example, to emulate first-come-first-serve, set all but the age-related parameters to zero (and, since there are no other metrics to compete with, simple values of newest=0, oldest=1, extreme_threshold=9999, extreme_value=2, or any other combination where newest < oldest < extreme_value, will work).
Customization tips
To make it easier to visualize this algorithm, see this playground https://codesandbox.io/s/di-scoring-playground-x4kqrw?file=/src/ChunkAdd.tsx. This makes it easy to simulate tenant usage and jobs of different ages, sizes, and tenants.
...
For example: the size of a chunk. If we expect chunks to typically have a size from 1 to 32, we could define scores 0 to 5. With this, we would get the following scores:
Value range | Score range |
|---|---|
[1,2] | (0,1] |
[3,4] | (1,2] |
[5,8] | (2,3] |
[9,16] | (3,4] |
[17,32] | (4,5]. This is the upper bound of the expected range, but since the real value could be infinite, it can keep going… |
[33,64] | (5,6] |
… | … towards ∞ |
Why is this a good approach?
...