We could save petabytes of cache storage with Zstandard and Pingora
blog.cloudflare.com
We could save petabytes of cache storage with Zstandard and Pingora
1–10 of 64 posts
Re: We could save petabytes of cache storage with Zstandard and Pingora
#2Re: We could save petabytes of cache storage with Zstandard and Pingora
#3Weird, I would have compressed cold content instead, if the goal was to save on CPU time during decode.
Re: We could save petabytes of cache storage with Zstandard and Pingora
#4> We initially considered limiting transcoding to popular content Weird, I would have compressed cold content instead, if the goal was to save on CPU time during decode.
Zstd 3 to 5 is nearly free in terms of not bottlenecking disk or network. Zstd 12 to 19 gives amazing compression results and still result in speedups when reading from disk. It really is a wonderful all purpose compressor.
One of the nice things about Zstd is if you try to compress an already compressed stream, it short circuits. So even if you are given say HVEC MP4 and run zstd -19 on it, it will "compress" immediately and not DOS your pipeline.
Re: We could save petabytes of cache storage with Zstandard and Pingora
#5Re: We could save petabytes of cache storage with Zstandard and Pingora
#6Re: We could save petabytes of cache storage with Zstandard and Pingora
#7I'm confused by how this affects range requests. Without compression, those can be easily satisfied by reading the relevant part of the cached complete file. But how are they handled now? The article claims "range requests remain unchanged", but I don't see how that's possible if the cache no longer stores the uncompressed data.
Re: We could save petabytes of cache storage with Zstandard and Pingora
#8I'm confused by how this affects range requests. Without compression, those can be easily satisfied by reading the relevant part of the cached complete file. But how are they handled now? The article claims "range requests remain unchanged", but I don't see how that's possible if the cache no longer stores the uncompressed data.
I assume the entire resource needs to be decompressed first, then indexed into, served, and discarded. Well, actually, you could just decompress up to the end of the range.
You could split the file into independently compressed blocks as well. But that'd reduce compression rate and require adding some kind of index for seeking.
Or they have an upper size limit for the file size they compress, since large files are rarely compressible text.
In any case it is something that needs the be handled before going live with a compressed cache. But the article sounds like they simply didn't implement compressed caching for those cases, which makes no sense.
Re: We could save petabytes of cache storage with Zstandard and Pingora
#9Why not serving files compressed if the client supports it even though the origin served an uncompressed file?