4 ms·

I think the implicit assumption in the comment is that it would be possible for readers to understand the underlying idea of the comment rather than only see th

by orf 4y ago

I think the implicit assumption in the comment is that it would be possible for readers to understand the underlying idea of the comment rather than only see the specific example. “resource cost per minute” is not the only thing helped by a non-empty queue. Also please don’t accuse someone of not “responding to the content of the article” when the content is a bog standard list. If you want my response to that: “yes, that is indeed a list of 4 things queues help with”. Not sure it adds much to the discussion.

anonymoushn 4y ago
When will my users be happier because I took longer to do things on their behalf? I apologize for not understanding the unwritten portion of the comment. I guess I should really ask, why do people care about utilization instead of throughput, latency, and cost? We could increase utilization by rewriting everything to be more wasteful, for example, but it doesn't seem like we should do it.
- zmgsabst 4y ago
  Utilization is choosing throughout and cost over latency. People care about utilization when, eg, processing petabytes of data — something that takes hours to days, where you’re optimizing batch throughout and cost. By making sure you efficiently utilize your hardware.
  - anonymoushn 4y ago
    > Utilization is choosing throughout and cost over latency. For a given rate of incoming work, increasing throughput decreases utilization. So I guess it's not choosing throughput too much. > People care about utilization when, eg, processing petabytes of data — something that takes hours to days, where you’re optimizing batch throughout and cost. By making sure you efficiently utilize your hardware. If you have fixed resources and lots of work, it would be good to have nonempty queues to prevent them from idling. That is maybe the big unwritten part of the comment upthread. It doesn't seem worth saying "no, the article is wrong in all cases because of this particular case!" though, so I'm not sure.
    - remram 4y ago
      If you define throughput as "processed items over time per processor", the tradeoff becomes clear. Given the rate of incoming requests, you can get more processors, which will increase cost and reduce latency and throughput-per-processor, or you can get fewer processors, which will decrease cost and increase latency and throughput-per-processor. If you have fixed resources and fixed work, wanting your queues to be empty is a wish, not a strategy.

by orf 4y ago

anonymoushn 4y ago

When will my users be happier because I took longer to do things on their behalf? I apologize for not understanding the unwritten portion of the comment. I guess I should really ask, why do people care about utilization instead of throughput, latency, and cost? We could increase utilization by rewriting everything to be more wasteful, for example, but it doesn't seem like we should do it.

zmgsabst 4y ago
Utilization is choosing throughout and cost over latency. People care about utilization when, eg, processing petabytes of data — something that takes hours to days, where you’re optimizing batch throughout and cost. By making sure you efficiently utilize your hardware.
- anonymoushn 4y ago
  > Utilization is choosing throughout and cost over latency. For a given rate of incoming work, increasing throughput decreases utilization. So I guess it's not choosing throughput too much. > People care about utilization when, eg, processing petabytes of data — something that takes hours to days, where you’re optimizing batch throughout and cost. By making sure you efficiently utilize your hardware. If you have fixed resources and lots of work, it would be good to have nonempty queues to prevent them from idling. That is maybe the big unwritten part of the comment upthread. It doesn't seem worth saying "no, the article is wrong in all cases because of this particular case!" though, so I'm not sure.
  - remram 4y ago
    If you define throughput as "processed items over time per processor", the tradeoff becomes clear. Given the rate of incoming requests, you can get more processors, which will increase cost and reduce latency and throughput-per-processor, or you can get fewer processors, which will decrease cost and increase latency and throughput-per-processor. If you have fixed resources and fixed work, wanting your queues to be empty is a wish, not a strategy.