Cannot disable request logging

I am trying to use GrpcMock for performance tests with Gatling.
I created a grpcMock server that returns the appropriate mock response for various requests based on request matching (unary grpc method in all cases). In other words, I specified the sample requests and sample responses for the GrpcMock server.
Gatling is used to check the responses received from the GrpcMock and make sure that the responses include the appropriate fields, they are completed in time, etc. and the requests are predefined thus I need no checks on the GrpcMock server.
The test works fine as long as I run it locally, though when I run it on the build server, the test fails due to slow response times. Note that there is a high amount of requests: the GrpcMock server receives 160 requests in 10 seconds.
I think the test could be completed faster if I had an option to disable the logging of the received requests on the GrpcMock server.
I could not find any workaround to bypass the RequestCaptureInterceptor.
This interceptor is always passed to the server when it is built.
Could you add a configuration option to disable this interceptor? Or maybe make it optional to pass interceptors to the mock server?

Hi @balazs-n, RequestCaptureInterceptor is an essential part of GrpcMock's matching capabilities, so it cannot be removed, but have you tried changing the logging level for org.grpcmock.GrpcMock to WARN/ERROR?
Also from what you've described I doubt that it's related to the interceptor or logging. Sounds like your CI/remote server just doesn't have enough resources to service that many requests in a given time period with current config. Probably your instance also has a low CPU count and you haven't configured a custom Executor for the server, which by default uses newCachedThreadPool AFAIR. So maybe try playing with that as well and see if it helps.

Hi @Fadelis , indeed setting the log levels to ERROR helped, p95 response times decreased from 10,000 ms to ~80 ms.
Currently there is no Executor configured for the server, though that might further improve performance. Do you have any sample configuration in mind?

@balazs-n glad it helped, maybe you have really large request bodies, since it affected performance so drastically?

Do you have any sample configuration in mind?

That's something that you'll have to play around and tailor to your needs. The default one works pretty well in most situations, but might not be the best one in some cases. You can specify the Executor when building GrpcMock -

grpcmock/grpcmock-core/src/main/java/org/grpcmock/GrpcMockBuilder.java

Lines 41 to 44 in 17af82c

    
           public GrpcMockBuilder executor(@Nullable Executor executor) { 
        
             serverBuilder.executor(executor); 
        
             return this; 
        
           }

You could try using fixed thread executor with 2*cores, or work stealing executor and see if it helps.

	public GrpcMockBuilder executor(@Nullable Executor executor) {
	serverBuilder.executor(executor);
	return this;
	}