Vert.x delayed response during send - vert.x

Question

We are running a vertx HTTPS server on cloud using ubi8 OpenJDK 17 image. The resources assigned to container are 2 Core CPU and 8 GB RAM. This is the server startup parameter for the vertx 4.2.7 application.
-Xms954m -Xmx3815m -XX:+UnlockExperimentalVMOptions -XX:+UseZGC -XX:MinHeapFreeRatio=10 -XX:MaxHeapFreeRatio=20 -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90 -XX:+ExitOnOutOfmoryError -Dvertx.disableDnsResolver=true
We have enabled epoll and BoringSSL, set the blocked thread checker to check thread blocked for more than 100 msec and starting the server with following flags.
.setSendBufferSize(30 * 1024) // 30 KB
.setReceiveBufferSize(1 * 1024) // 1 KB
.setTcpFastOpen(true)
.setTcpNoDelay(true)
.setTcpQuickAck(true)
.setTcpCork(false)
.setReusePort(true)
.setReuseAddress(true)
.setTcpKeepAlive(true)
.setCompressionSupported(true)
.setUseAlpn(true)
.setHandle100ContinueAutomatically(true)
.setTracingPolicy(TracingPolicy.IGNORE)
.setSsl(true)
.setSslEngineOptions(new OpenSSLEngineOptions().setSessionCacheEnabled(false))
.setKeyStoreOptions(new JksOptions().setPath(config.getJsonObject(ConfigConstants.SSL).getString(ConfigConstants.KEY_STORE)).setPassword(config.getJsonObject(ConfigConstants.SSL).getString(ConfigConstants.CERTIFICATE_PASSWORD)));
We also have the LoggingHandler as the first Handler in the chain.
This is how we are sending the response
routingContext.response()
.setChunked(true)
.putHeader(HttpHeaders.CONTENT_TYPE.toString(), HttpConstants.APPLICATION_HAL_JSON)
.putHeader(HttpConstants.IDENTIFIER, requestObject.getPathParams().get(UrlConstants.IDENTIFIER))
.end(response.encode());
We are seeing that the LoggingHandler reports that the server has taken 1 ms to process the request whereas at client end (for 0.1% of request), we see that the server time and the client reported time do not match. We created a JMH test and used OkHttp at client end and we are seeing this in the logs for the request for which server took 1 ms.
Req # Time Operation
67997 0.000 callStart
67997 0.000 connectionAcquired
67997 0.000 requestHeadersStart
67997 0.000 requestHeadersEnd
67997 0.423 responseHeadersStart
67997 0.423 responseHeadersEnd
67997 0.427 responseBodyStart
67997 0.427 responseBodyEnd
67997 0.427 connectionReleased
67997 0.427 callEnd
Any clues to narrow down the problem to find the root cause ?