We are doing some performance testing sending workflow execution requests to a self-hosted temporal cluster using newUntypedWorkflowStub.startWorkflow().
Dynatrace is showing some waiting time and on the distribution we are seeing the GrpcRetryer.retryWithResult().
I am not that familiar with gRPC (so I read a bit about it) and would like to understand a bit how the connection between the temporal service client and the frontend service works with the default service stubs options configuration and potentially if there is anything we can do to reduce the waiting time at the locations mentioned above.
Is only one channel used for the communication ?
What is the default number of connections in a channel ? Is it configurable in the java-sdk ?
How much avg time can we expect for a connection to be freed ?
What is the default number of connections in a channel ? Is it configurable in the java-sdk ?
How much avg time can we expect for a connection to be freed ?
gRPC maintains the connection pool and handles the freeing/re-establishing connections. SDK does expose raw gRPC options via ServiceStubsOptions (check setChannelInitializer) so you can configure gRPC channel as you like if needed.
GrpcRetryer.retryWithResult().
I think this can be in stack trace even if first attempt is successful. How many of these traces do you see?
gRPC maintains the connection pool and handles the freeing/re-establishing connections. SDK does expose raw gRPC options via ServiceStubsOptions (check setChannelInitializer) so you can configure gRPC channel as you like if needed.
Would you have any guidance/resources for the channel configuration ?
I think this can be in stack trace even if first attempt is successful. How many of these traces do you see?
This was actually the only one I could see from the monitoring tool.