9 ms·

Since apparently no one is willing to read this excellent article, which even comes with fun sliders and charts... > It turns out that Chrome actively throttle

Since apparently no one is willing to read this excellent article, which even comes with fun sliders and charts... > It turns out that Chrome actively throttles requests, including those to cached resources, to reduce I/O contention. This generally improves performance, but will mean that pages with a large number of cached resources will see a slower retrieval time for each resource.

cogman10 4y ago
Seems like a shortcut that shouldn't be. I can understand throttling network requests, but disk requests? The only reason to do that would be for power savings (you don't want to push the CPU into a higher state as it loads up the data).
- sieabahlpark 4y ago
- staticassertion 4y ago
  I imagine it's just that the cache is in an awkward place where the throttling logic is unaware of the cache and the cache is not able to preempt the throttling logic.
  - cogman10 4y ago
    I'd guess the same thing is going on. Definitely FEELS like a code structure problem.
- fnordpiglet 4y ago
  Depends on if you value latency for the user. Saying I try both and choose the one coming first hurts no one but the servers not being protected by a client cache. But there’s absolutely no reason to believe a client has a cache that masks requests. AFAIK there’s no standard that says clients use caches for parsimony and not exclusively latency. As a matter of fact I think this is a good idea if it ever takes time to consult the cache, and the trade off is more bandwidth consumption which we are awash in. If you care that much run a caching proxy and use that and you’ll get the same effect of the client side cache masking requests. But I would say it’s superior because it always uses the local cache first and doesn’t waste user time on the edge condition in their cache coherency. It comes from Netscape which famously convinced everyone that it’s one of the hardest problems. That leads to the final benefit, the cache doesn’t have to cohere. If it’s too expensive at that moment to cohere and query then I can use the network source. Again the only downside is the network bandwidth is more consistently user. I would be hard pressed to believe most Firefox users already are grossly bandwidth over provisioned, and the amount of a fraction of a cable line a web browser loading from the cache no one could even notice that.
  - cogman10 4y ago
    > Depends on if you value latency for the user. I do. Which is why it's silly to throttle the cache IO. The read latency for disks is measured in microseconds. Is it possible for the server to be able to respond faster? Sure. However, if you aren't within 20 miles of the server then I can't see how it could be faster (speed of light and everything). These design considerations will depend greatly on where you are at. It MIGHT be the case that eschewing a client cache in a server to server talk is the right move because your servers are likely physically close together. That'd mean the server can do a better job making multiple client requests faster through caching saving the memory/disk space required for the clients. There is also the power consideration. It take a lot more power for a cell phone to handle a network request than it does to handle a disk request. Shouting into the ether isn't cheap.
    - Spooky23 4y ago
      What happens when your 200 browser tabs are all looking for updates?
      - cogman10 4y ago
        If your 200 browser tabs are saturating your 8gbps link to your m.2 ssd, what do you think they'll do to your 10mbps connection to the internet?
        fnordpiglet 4y ago
        What if it’s a virus scan or some background indexer browning out io resources on the disk path, or given it’s a consumer browser, some malware eating up resources unbeknownst to the user of the browser. Surely you’ve experienced noisy neighbors :-) It’s an interesting approach because it removes the assumption browser caches mask volume for infrastructure purposes rather than user latency. I think you can overwhelm costs for low or no income services. If this is widely adopted we ask the providers of our servers to pay for that latency improvement.
      - citrin_ru 4y ago
pclmulqdq 4y ago
I am a systems engineer. I read the article title, then started reading the article, and realized it was a bait and switch. It is not about "network" vs "cache" in computer systems terms, which is what you might expect. It is about "network" vs "the (usually antiquated) file-backed database your browser calls a cache." The former would have been a compelling article. The latter is kind of self-evident: the browser cache is there to save bandwidth, not to be faster.
- staticassertion 4y ago
  I find it odd to call it a bait and switch when the first thing in the article is an outline. > It is about "network" vs "the (usually antiquated) file-backed database your browser calls a cache." It's actually nothing to do with the design of the cache itself as far as I can tell. If you finish reading the article you'll see that it's about a throttling behavior that interacts poorly with the common optimization advice for HTTP 1.1+, exposed by caching. > The latter is kind of self-evident: the browser cache is there to save bandwidth, not to be faster. I don't think that's something you can just state definitively. I suspect most people do in fact view the cache as an optimization for latency. Especially since right at the start of the article, the first sentence, the "race the cache" optimization is introduced - an optimization that is clearly for latency and not bandwidth purposes.
  - karmakaze 4y ago
    It is a bait and switch. The issue is with local files and throttling, neither word appears in the title or outline. Edit: I didn't need this post to tell me about the "waiting for cache" message I used to see with Chrome.
    - dchftcs 4y ago
      When I see "browser cache" I can't think of anything other than a local file storage. Maybe it confused you, but there's no deliberate misleading.
      - 4y ago

cogman10 4y ago

Seems like a shortcut that shouldn't be. I can understand throttling network requests, but disk requests? The only reason to do that would be for power savings (you don't want to push the CPU into a higher state as it loads up the data).

sieabahlpark 4y ago
staticassertion 4y ago
I imagine it's just that the cache is in an awkward place where the throttling logic is unaware of the cache and the cache is not able to preempt the throttling logic.
- cogman10 4y ago
  I'd guess the same thing is going on. Definitely FEELS like a code structure problem.
fnordpiglet 4y ago
Depends on if you value latency for the user. Saying I try both and choose the one coming first hurts no one but the servers not being protected by a client cache. But there’s absolutely no reason to believe a client has a cache that masks requests. AFAIK there’s no standard that says clients use caches for parsimony and not exclusively latency. As a matter of fact I think this is a good idea if it ever takes time to consult the cache, and the trade off is more bandwidth consumption which we are awash in. If you care that much run a caching proxy and use that and you’ll get the same effect of the client side cache masking requests. But I would say it’s superior because it always uses the local cache first and doesn’t waste user time on the edge condition in their cache coherency. It comes from Netscape which famously convinced everyone that it’s one of the hardest problems. That leads to the final benefit, the cache doesn’t have to cohere. If it’s too expensive at that moment to cohere and query then I can use the network source. Again the only downside is the network bandwidth is more consistently user. I would be hard pressed to believe most Firefox users already are grossly bandwidth over provisioned, and the amount of a fraction of a cable line a web browser loading from the cache no one could even notice that.
- cogman10 4y ago
  > Depends on if you value latency for the user. I do. Which is why it's silly to throttle the cache IO. The read latency for disks is measured in microseconds. Is it possible for the server to be able to respond faster? Sure. However, if you aren't within 20 miles of the server then I can't see how it could be faster (speed of light and everything). These design considerations will depend greatly on where you are at. It MIGHT be the case that eschewing a client cache in a server to server talk is the right move because your servers are likely physically close together. That'd mean the server can do a better job making multiple client requests faster through caching saving the memory/disk space required for the clients. There is also the power consideration. It take a lot more power for a cell phone to handle a network request than it does to handle a disk request. Shouting into the ether isn't cheap.
  - Spooky23 4y ago
    What happens when your 200 browser tabs are all looking for updates?
    - cogman10 4y ago
      If your 200 browser tabs are saturating your 8gbps link to your m.2 ssd, what do you think they'll do to your 10mbps connection to the internet?
      - fnordpiglet 4y ago
        What if it’s a virus scan or some background indexer browning out io resources on the disk path, or given it’s a consumer browser, some malware eating up resources unbeknownst to the user of the browser. Surely you’ve experienced noisy neighbors :-) It’s an interesting approach because it removes the assumption browser caches mask volume for infrastructure purposes rather than user latency. I think you can overwhelm costs for low or no income services. If this is widely adopted we ask the providers of our servers to pay for that latency improvement.
    - citrin_ru 4y ago

pclmulqdq 4y ago

I am a systems engineer. I read the article title, then started reading the article, and realized it was a bait and switch. It is not about "network" vs "cache" in computer systems terms, which is what you might expect. It is about "network" vs "the (usually antiquated) file-backed database your browser calls a cache." The former would have been a compelling article. The latter is kind of self-evident: the browser cache is there to save bandwidth, not to be faster.

staticassertion 4y ago
I find it odd to call it a bait and switch when the first thing in the article is an outline. > It is about "network" vs "the (usually antiquated) file-backed database your browser calls a cache." It's actually nothing to do with the design of the cache itself as far as I can tell. If you finish reading the article you'll see that it's about a throttling behavior that interacts poorly with the common optimization advice for HTTP 1.1+, exposed by caching. > The latter is kind of self-evident: the browser cache is there to save bandwidth, not to be faster. I don't think that's something you can just state definitively. I suspect most people do in fact view the cache as an optimization for latency. Especially since right at the start of the article, the first sentence, the "race the cache" optimization is introduced - an optimization that is clearly for latency and not bandwidth purposes.
- karmakaze 4y ago
  It is a bait and switch. The issue is with local files and throttling, neither word appears in the title or outline. Edit: I didn't need this post to tell me about the "waiting for cache" message I used to see with Chrome.
  - dchftcs 4y ago
    When I see "browser cache" I can't think of anything other than a local file storage. Maybe it confused you, but there's no deliberate misleading.
    - 4y ago