3 ms·

ETags are brilliant at reducing bandwidth and work especially well if the origin webserver is close to the client. Unfortunately, there isn't a lot it can do ab

ETags are brilliant at reducing bandwidth and work especially well if the origin webserver is close to the client. Unfortunately, there isn't a lot it can do about round trip latency. Even if the payload resides on a proxy cache close to the client, that proxy cannot instantly answer 304 Not changed because it needs to revalidate its cache with its upstream as well (using If-None-Match). So, serving a (relatively small) cvsbase Bay Area to Australia will still be slow unless you're willing to accept stale data (Ie. Cache-Control: max-age / Expires headers).

zer00eyz 3y ago
Ohh this is an interesting case. You could abuse the hell out of Etags, Urls and DIFFS to get a much better long haul response. https://csvbase.com/user-name/table-name/ https://csvbase.com/user-name/table-name/ would return you an etag. The etag needs to be a hash of the file (sha256). https://csvbase.com/user-name/table-name/etag https://csvbase.com/user-name/table-name/etag could return a 204 for an unchanged document. If the two dont match then return a diff + new etag. Apply the diff as a patch, and check the etag. Yes you still have the latency, on 204's but the moment there is a change you might be getting a 200 from cache, and only a diff at that. Smaller payload and potentialy faster response. On the server side the only thing that you're adding in is the diff of the last change.... If the data is faster moving then "cache" should let you catch up. If the caches are stale then the first response will give you a patch and new etag that wont have the correct hash value and you know to grab a fresh copy as you have no path forward.
- repelsteeltje 3y ago
  Ultimately, the root cause of latency is the round trip time to figure out if the cache is valid. For large distance between client and source of truth there is not much you can do in terms of caching, diffs an other throughput conserving cleverness; it's the speed of light. Sometimes, however, it it possible to anticipate when content will become stale: when changes to the origin don't happen arbitrarily. For instance, with live media streaming, segment chunks are usually fixed duration (say 2s or 8s for Apple HLS) and so you know your content won't / shouldn't change until... In those cases, client (and caching proxies) can rely on expiration and do not need to revalidate which saves network traffic. But more importantly, it allows an edge server to instantly serve a cached copy to the client. The round-trip is essentially between the client device and edge server. Making that snappy might even reduce air time and save your phone battery.
mrighele 3y ago
If the main concern is latency, you could have the main store send push notifications to the caches (not client) whenever some data has been modified. Not something trivial, but I think it is doable if you have control of both the origin server and the intermediate cache.
RenThraysk 3y ago
Cache-Control: immutable will prevent roundtrips in atleast Firefox. This does mean that the path should be unique per version of the content. Like inserting a cryptographic hash in the path.

zer00eyz 3y ago

Ohh this is an interesting case. You could abuse the hell out of Etags, Urls and DIFFS to get a much better long haul response. https://csvbase.com/user-name/table-name/ https://csvbase.com/user-name/table-name/ would return you an etag. The etag needs to be a hash of the file (sha256). https://csvbase.com/user-name/table-name/etag https://csvbase.com/user-name/table-name/etag could return a 204 for an unchanged document. If the two dont match then return a diff + new etag. Apply the diff as a patch, and check the etag. Yes you still have the latency, on 204's but the moment there is a change you might be getting a 200 from cache, and only a diff at that. Smaller payload and potentialy faster response. On the server side the only thing that you're adding in is the diff of the last change.... If the data is faster moving then "cache" should let you catch up. If the caches are stale then the first response will give you a patch and new etag that wont have the correct hash value and you know to grab a fresh copy as you have no path forward.

repelsteeltje 3y ago
Ultimately, the root cause of latency is the round trip time to figure out if the cache is valid. For large distance between client and source of truth there is not much you can do in terms of caching, diffs an other throughput conserving cleverness; it's the speed of light. Sometimes, however, it it possible to anticipate when content will become stale: when changes to the origin don't happen arbitrarily. For instance, with live media streaming, segment chunks are usually fixed duration (say 2s or 8s for Apple HLS) and so you know your content won't / shouldn't change until... In those cases, client (and caching proxies) can rely on expiration and do not need to revalidate which saves network traffic. But more importantly, it allows an edge server to instantly serve a cached copy to the client. The round-trip is essentially between the client device and edge server. Making that snappy might even reduce air time and save your phone battery.

mrighele 3y ago

If the main concern is latency, you could have the main store send push notifications to the caches (not client) whenever some data has been modified. Not something trivial, but I think it is doable if you have control of both the origin server and the intermediate cache.

RenThraysk 3y ago

Cache-Control: immutable will prevent roundtrips in atleast Firefox. This does mean that the path should be unique per version of the content. Like inserting a cryptographic hash in the path.