8 ms·

From my understanding the better policy will be to prioritise the smallest assets first. To me it seems counter-intuitive but apparently it proves out in theory

From my understanding the better policy will be to prioritise the smallest assets first. To me it seems counter-intuitive but apparently it proves out in theory and testing: https://www.cs.cmu.edu/~harchol/Papers/usits1.pdf https://www.cs.cmu.edu/~harchol/Papers/usits1.pdf More dramatic improvement might be possible if streams can be interrupted and resumed (which is something protocols like RSocket support): https://www.cs.cmu.edu/~harchol/Papers/MIT-LCS-TR-767.pdf https://www.cs.cmu.edu/~harchol/Papers/MIT-LCS-TR-767.pdf Apologies if you're already familiar with these.

lucaspardue 7y ago
These papers are interesting, thanks for sharing. However, the primary axiom is of a web server that is serving static content that is located on the device. That, in a sense, gives almost infinite time and knowledge to deciding prioritisation of work. For HTTP proxies that have to fetch resources from some other server, the time and knowledge window becomes much shorter. Decision making needs to be done quickly in order to minimise the latency of returning anything. And the upstream server may response in unexpected ways. This is the challenge for today's CDN deployments. And developing a solution that works for the huge variety of how websites are developed is the really interesting bit.
- jacques_chester 7y ago
  I'm not sure I follow. Proxies don't have much time to reorder from an upstream on the first time writing through to their downstream. But once it's in their local cache it would become possible to apply the smallest-first logic, wouldn't it?
  - lucaspardue 7y ago
    This depends on how the proxy is configured to behave. One common pattern is to have a protocol terminating proxy talk to the client. Other component(s) sit behind this and they could be other parts of the system, tiers of caches or tiers of CDNs. Even if the proxy does cache locally to memory or disk. Without infinite space, there will be some chance of cache eviction and a need to fetch from the upstream again. Our scenarios are different ends of a broad spectrum, and there's a lot in between. Which is why getting prioritisation right is a hard nut to crack.

lucaspardue 7y ago

These papers are interesting, thanks for sharing. However, the primary axiom is of a web server that is serving static content that is located on the device. That, in a sense, gives almost infinite time and knowledge to deciding prioritisation of work. For HTTP proxies that have to fetch resources from some other server, the time and knowledge window becomes much shorter. Decision making needs to be done quickly in order to minimise the latency of returning anything. And the upstream server may response in unexpected ways. This is the challenge for today's CDN deployments. And developing a solution that works for the huge variety of how websites are developed is the really interesting bit.

jacques_chester 7y ago
I'm not sure I follow. Proxies don't have much time to reorder from an upstream on the first time writing through to their downstream. But once it's in their local cache it would become possible to apply the smallest-first logic, wouldn't it?
- lucaspardue 7y ago
  This depends on how the proxy is configured to behave. One common pattern is to have a protocol terminating proxy talk to the client. Other component(s) sit behind this and they could be other parts of the system, tiers of caches or tiers of CDNs. Even if the proxy does cache locally to memory or disk. Without infinite space, there will be some chance of cache eviction and a need to fetch from the upstream again. Our scenarios are different ends of a broad spectrum, and there's a lot in between. Which is why getting prioritisation right is a hard nut to crack.