> If a queue isn't approaching empty, then its input is exceeding its output.
It depends what you mean by "approaching empty". If you mean "empty most of the time", then no, that's wasted resources. If you mean "its size is decreasing most of the time", then no, not possible. Even if you mean "it is empty some of the time", then maybe, but that is not a strong requirement either.
Of course more average input than average output is bad, but stating it as "should be empty" or "should be approaching empty" seem to suggest the wrong thing entirely. It should be smaller than the target latency of the process.
Eh? It is possible for size to be decreasing most of the time. Just make traffic extremely bursty - add 60 on the hour every hour, and consume at one per minute.
What does average mean there? Increasing and decreasing are punctual events. If you mean the 1-minute average can be negative most of the time, that is true, but it would not work for other time horizons, whether larger or shorter.
the # of items in a queue is either growing or shrinking, there isn't the concept of "staying the same" and as you approach the line from shrinking to growing, performance (queue time) degrades after roughly 70-75% utilization.
You can only assert that it's "shrinking" or "growing" over a given period of time. It may have been shrinking over the last 5min while at the same time it has grown over the last hour. For a time window small enough, it has not changed, because getting 1 input or 1 output is a punctual event. For a time window large enough, it has necessarily grown, if it started empty.
So I disagree entirely with "it's either shrinking or growing". It is both growing, shrinking, and stable, at the same time, over different horizons, and I have no idea what law you are trying to state.
The link you provided above is a really good primer based on serious math, I don't understand how you think it supports your vague claims.
I think you should read up on this a little bit as your assumptions are not totally correct, and if you're using queues understanding this theory is pretty important and will save you some headaches.
Queues are either growing (adding items) or getting smaller (consuming items). There is not a state where they stay the same length, unless you're doing something really weird like monitoring to make sure there are always 10 items in the queue, or something, and adding if that number drops, but then you'd need a second queue-type structure to support that, and the conversation kind of goes off the rails.
It's a point in time, but it is irrelevant to the problem we're discussing and I'm not sure what value there is in discussing that static points in time exist. It's like discussing a runtime and saying "well, at this static point in time it takes zero seconds to run" - I just can't wrap my head around how it is relevant to the issue at hand.
You're also being really rude for no good reason. My polite suggestion is that you reflect on yourself here about why you are being rude on the internet to strangers. It could lead to growth and hopefully help you with whatever hurt you're experiencing.
It depends what you mean by "approaching empty". If you mean "empty most of the time", then no, that's wasted resources. If you mean "its size is decreasing most of the time", then no, not possible. Even if you mean "it is empty some of the time", then maybe, but that is not a strong requirement either.
Of course more average input than average output is bad, but stating it as "should be empty" or "should be approaching empty" seem to suggest the wrong thing entirely. It should be smaller than the target latency of the process.