Hey everyone! I'm developing a ktor API that will ...

# ktor

[Gustavo Cesário]

Hey everyone! I'm developing a ktor API that will be stress tested with k6. The main endpoint only receives a request and adds it to a Channel so it can be consumed by another process. During the first stages of the stress test I can see response times of 1ms~2ms. However, in later stages of the stress test the response times quickly rise to 200ms or even 500ms. The amount of total requests is approximately 15k in one minute. I'd really appreciate some insights of what I could investigate to try to understand those latency spikes. Here is some information about the application:
• I built a native image with GraalVM
• I'm running on very limited resources (0.6 cpu cores and 160MB of ram)
• The application is running in a docker-compose environment
• "docker stats" shows that the average cpu usage is 20% and memory usage is 50%.
• The endpoint is only responsible for deserializing the request and adding it to the Channel.

post("/payments") {
            try {
                val request = call.receive<PaymentRequest>()
                QueueService.addPaymentRequestToQueue(request)
                call.respond(HttpStatusCode.Accepted)
            } catch (e: Exception) {
                call.respond(HttpStatusCode.InternalServerError, "Error processing payment request: ${e.message}")
            }
        }

• I already tried to wrap QueueService.addPaymentRequestToQueue in launch {}.
• There are other coroutines running at the same time in my application.
I'm new to coroutines and ktor, so I'm afraid that I might have messed something with the dispatchers and how I'm creating the coroutines. What could I do to investigate what the problem is?

[Aleksei Tirman [JB]]

Can you reproduce the problem by running the application on JVM, rather than as a native image? If so, I suggest using a JVM profiler to determine where the bottleneck is.

[CLOVIS]

A JVM profile won't help much in a coroutines-based app, especially with queues

[CLOVIS]

It sounds like it's receiving requests faster than it can process them?

[Gustavo Cesário]

@Aleksei Tirman [JB] In the JVM it works fine, with a constant response time of 1~4ms.

[Gustavo Cesário]

@CLOVIS I don't think so, the "process" is just adding to a in-memory queue, just fire and forget. The response time is very constant for most part of the test, but then it suddenly spikes to 300+ms.