Grzegorz Lukasik

Note that protobuf ApiV2 is using aliases from old api to new api for well known types (e.g. [empty.pb.go](https://github.com/golang/protobuf/blob/91c84e0db17890c2bb64280a6d660e73e4237fd1/ptypes/empty/empty.pb.go#L15)), what changes the code generated by mockgen after upgrading protobuf package...

Option to change `grpc_server_handled_total` - or something similar - to expose binary SUCCESS / FAILURE status instead of having one label per status.

Symptom was that bazel-remote started to work very slowly after a few hours of working. Note, that it's used as a backed in build-barn setup. Other symptom was that memory...

Missed one important detail: when investigating the issue, found out in bazel stack traces that bazel client was hanging on `findMissingBlobs`. Reproducing the RPC call manually, was working very long...

Looks like https://github.com/googleapis/google-cloud-go/pull/6266 fixed the issue for google storage, verified that the issue is present before this PR and vanishes after this PR. This fix is not released yet, but...

Added WIP implementation: https://github.com/buchgr/bazel-remote/pull/485 For now results for downloading files are promising (40% overhead of enabling zstd instead of 160%), but looks like overhead of uploading files is too high...

Marked #485 as ready for review, the overhead of compression is actually expected.

I have collected some initial data to check whether deduplication caused by chunking would be helpful to reduce size of the data. Focused on data residing in cache, checking in-flight...

Also, from somewhat related item on bazel side: [remote/performance: support rsync compression ](https://github.com/bazelbuild/bazel/issues/4845) > In early experiments we are seeing up to 90% reduction in required download bandwidth. The result...

> IIRC @erikma and @johnterickson reported that transferring large files in parallel using chunks was significantly faster with azure blob storage than a single upload/download stream (and I imagine S3...