Allow connection to a gRPC server in the init context

[rbharvs]

Feature Description

When performance testing a gRPC server, it would be ideal if k6 allowed grpc::connect to be called in the init context so that the channel can be reused for the same VU across iterations. As noted here:

A gRPC channel should be reused when making gRPC calls. Reusing a channel allows calls to be multiplexed through an existing HTTP/2 connection.

If a new channel is created for each gRPC call then the amount of time it takes to complete can increase significantly. Each call will require multiple network round-trips between the client and the server to create a new HTTP/2 connection.

Enabling this would make for more realistic performance tests.

Any thoughts on whether this might be feasible?

Suggested Solution (optional)

No response

Already existing or connected issues / PRs (optional)

No response

[na--]

Sorry for the super-long delay in responding, I forgot to do so earlier in the week 😞

We don't want to implement features that require network connections in the init context, for a few important reasons:

• initialization of transient VUs happens more often than expected (e.g. for getting the initial exported options, for setup() and teardown() execution, for running handleSummary())
• network requests in the init context will cause VUs to be initialized more slowly
• any errors in initializing VUs will cause the whole test to be aborted, and network calls are particularly error-prone
• VUs can be reused between non-overlapping scenarios

So, we'd prefer to keep VU initialization as side-effect free as possible. What you can do instead is to use the k6/execution API to see if this is the VU's first iteration in the scenario and to call the client.connect() call if it is. Something like this:

import grpc from 'k6/net/grpc';
import exec from 'k6/execution';

const client = new grpc.Client();
client.load(/* ... */);

export default () => {
  if (exec.vu.iterationInScenario == 0) {
    client.connect(/* ... */);
  }
  client.invoke(/* ... */);
  // ...
  // Do NOT close the client
};

It's not a great workaround, since it will increase the iteration_duration value of the first iterations, but it's what we can currently do 😞 We plan to hopefully address this in another way by implementing things like per-VU init lifecycle functions (#785) or per-scenario setup() (#1638) or some mix between the two. So follow these issues for updates, but I'll have to close this one, since having network requests in the init contexts is a no-go with the current k6 architecture, sorry.

[rbharvs]

Thank you for the detailed reply. At least we can get a lower bound on performance 🙂 I'm really loving this tool. And thank you for the workaround, we'll give it a shot.