Add discardResponseMessage option for gRPC client

[lzakharov]

What?

Adds a new gRPC client option discardResponseMessage, which is equivalent to discardResponseBodies.

Why?

Parsing heavy responses can result in high CPU and memory usage.

Checklist

• I have performed a self-review of my code.
• I have added tests for my changes.
• I have run linter locally (make lint) and all checks pass.
• I have run tests locally (make tests) and all tests pass.
• I have commented on my code, particularly in hard-to-understand areas.

Related PR(s)/Issue(s)

#2497

[CLAassistant]

All committers have signed the CLA.

[codebien]

Hi @lzakharov,
sorry for the late review. Thanks for your contribution 🙇

Did you run the profiler to make sure it reduces the memory as expected?

After checking a bit the gRPC library, I assume that we are not discarding the response body as we do in HTTP.
With the suggested code, we are mostly only skipping the JSON parsing. That might lead to not being very useful in reducing memory usage. It might be more impactful on the CPU.

[lzakharov]

Hi, thanks for your review comment!

By reducing memory consumption, I meant the absence of the need to allocate objects when parsing into JSON. I don't yet know how to fully ignore a message at the gRPC library side, need to do some research. My main focus was on CPU consumption, since this is the problem we encountered in our tests.

[lzakharov]

After some research, I discovered that emptypb.Empty can be used as a response message type to reduce memory consumption. It still requires reading all response data into the bytes buffer here, but I haven't found how to optimize this. Anyway, the current solution shows a noticeable improvement in performance.

To compare performance, I modified the gRPC server from the testutils package to include an RPC method that returns a list of features for a specified rectangle (with the same logic as in ListFeatures).

Without the discardResponseMessage option:

k6 ➜  /usr/bin/time -l -h ./k6 run --vus 100 --iterations 10000 examples/grpc_invoke.js
...
        3.54s real              10.84s user             1.44s sys
           190300160  maximum resident set size
                   0  average shared memory size
                   0  average unshared data size
                   0  average unshared stack size
               10594  page reclaims
                1562  page faults
                   0  swaps
                   0  block input operations
                   0  block output operations
               49785  messages sent
               28878  messages received
                4900  signals received
                1661  voluntary context switches
               83331  involuntary context switches
         90855390651  instructions retired
         35639318415  cycles elapsed
           164775808  peak memory footprint

With the discardResponseMessage option:

k6 ➜  /usr/bin/time -l -h ./k6 run --vus 100 --iterations 10000 examples/grpc_invoke_discard.js
...
        3.89s real              4.71s user              1.89s sys
           137052160  maximum resident set size
                   0  average shared memory size
                   0  average unshared data size
                   0  average unshared stack size
                8839  page reclaims
                   2  page faults
                   0  swaps
                   0  block input operations
                   0  block output operations
               51883  messages sent
               29678  messages received
                1760  signals received
                 516  voluntary context switches
              177455  involuntary context switches
         31404551635  instructions retired
         19073852897  cycles elapsed
           111707968  peak memory footprint

[codebien]

Hey @lzakharov,
the results are quite interesting! Thanks for taking care of it.

If we can find an alternative solution to the current global variable then we are fine with merging your proposal. 👍

It would be helpful if you could do something similar also for gRPC streaming. You can split it in a second pull request.

[lzakharov]

It would be helpful if you could do something similar also for gRPC streaming. You can split it in a second pull request.

I'll try to add it in the next PR.

[codebien]

LGTM

[mstoykov]

LGTM!

Thanks for the contribution @lzakharov 🙇