> An extremely useful law to remember....
Would you be willing to provide an example where you applied Little's Law?
Would you be willing to provide an example where you applied Little's Law?
The decision was still made to alter the priority. The change went into production and was found to unacceptably degrade the performance of other jobs. Thankfully, one of the engineers who I had convinced that "processing time is the only factor that matters" had spent all their time optimizing the heavy task, to the point where it was no longer a heavy task, thus saving the day.
0. The job was some kind of "export CSV" form, and it somehow involved both 'traversing dozens of highly normalised tables' and 'digging into json blobs stored as text'.
1. I specifically remember one of the arguments was that if you have 3 heavy tasks A B and C, best case is "in parallel" which takes max(A, B, C) time whereas worst case is "sequential" which takes (A) + (B + A) + (C + B + A) time, our current priority approximated the "sequential" scenario, and the priority change would instead approximate the "parallel" scenario. I use scare quotes because I felt it was a resource issue (the "sequential" pattern was a byproduct of the most common way a heavy task got enough resources... which was an earlier heavy task finished and freed up a lot of resources).
The ONLY time thats not true is if higher priority tasks would eliminate the need for other tasks.
It's the most primitive application but immediately useful for anyone.
I've used similar methods to estimate work lag: https://two-wrongs.com/estimating-work-lag.html
And to argue for concurrency limits in latency-sensitive backend serviced.