whateverable icon indicating copy to clipboard operation
whateverable copied to clipboard

Implement some sort of a cache

Open AlexDaniel opened this issue 8 years ago • 5 comments

Most queries are using HEAD and “releases”, there is no need to extract these files each time (wasting 0.2s on each archive each time).

In fact, it looks like even Benchable is not smart enough to not work with archives all the time (see this). Some kind of a global cache will eliminate the need to fix Benchable.

AlexDaniel avatar Sep 13 '16 02:09 AlexDaniel

Interesting issue. See #117 also.

Basically, we have something like this:

  • Builds that are in long-term storage mode, where 20 builds are put into the same archive to save space
    • using lrz
    • extremely low disk usage (≈10 MiB per archive, which is ≈0.5 MiB per build)
    • <2 seconds to extract required build
  • Normally archived builds, where each build is in its own archive
    • using zstd
    • low disk usage (≈4.7 MiB per archive/build)
    • <0.2 seconds to extract required build
  • A new level proposed by this ticket
    • using nothing, the build is left on the disk uncompressed
    • 28 MiB per build
    • Low to zero delay to get the required build

AlexDaniel avatar Jul 07 '17 17:07 AlexDaniel

I wonder if we should use lz4 for this. According to my measurements in #23, lz4 is just ≈38 milliseconds (≈30%) faster than zstd, so we are not winning anything this way? I'd consider 87ms delay to get the required build as too slow if we are talking about fast cache.

AlexDaniel avatar Jul 07 '17 17:07 AlexDaniel

You mean use lz4 for the fast path? Instead of uncompressed?

MasterDuke17 avatar Jul 07 '17 18:07 MasterDuke17

@MasterDuke17 yea…

AlexDaniel avatar Jul 07 '17 20:07 AlexDaniel

Anyway, IMO no need to use lz4, just leave the build uncompressed.

AlexDaniel avatar Jun 02 '18 12:06 AlexDaniel