Run mono in parallel doesn't seems faster

Issue

So I'm trying to make API request in parallel, but it doesn't seems any faster. Am I doing it wrong? Here are my codes.

 fun getUserInfo(username: String): Mono<String> {
        return webclient
            // some config and params
            .post()
            .bodyToMono(String::class)
            .subscribeOn(Schedulers.parallel())
}

fun main(){
    val time = measureTimeMillis {
        Mono.zip(getUserInfo("doge"), getUserInfo("cheems"), etc...)
            .map { user ->listOf(it.t1, it.t2, etc...) }
            .block()
    }
   // give the same amount of time doesn't seems faster 
   // with and without subscribeOn(Schedulers.parallel())
}

Solution

It has nothing to do with your code.

You must understand that any i/o-work is mostly spent waiting. As in waiting for a response.

If we look at the lifecycle of a thread, it will do a bit of preprocessing and then send the request. When the request has been sent it has to wait for the response. This is where the majority of the time is spent, then you get a response and process the response. Here's the thing, as much as 90% of the request time could be spent just waiting. This is a lot of wasted resources having the thread just waiting.

This is what is good with webflux/reactor. When a request is sent, the thread will not wait, it will go on to process other requests/responses, and when that first requests response comes back, any free thread can pick up that response, it does not have to the be the thread that sent the request in the first place.

What i have just described is usually what is called async or asynchronous work.

So lets look at what you are doing. You want to run your requests in parallel, meaning utilizing multiple threads on multiple cores at the same time.

For this to work, you will need to contact the other cpus and tell them to get prepared for incoming work. The cpus will then need to initialize a number of threads on each cpu and then the data must be sent to all the cpus. As you can see there is a setup time involved here.

Then all the requests are made from multiple cpus at the same time, but the waiting for the responses are constant! Its the exact same waiting time as before (up to as much as 90% of the total request time). Then when all responses are return they are collected and processed on multiple cpus, and then they are sent back to the original thread on the original cpu.

What have you gained? Most likely almost nothing, but you also most likely utilized a lot more resources for this very, very minimal gain.

Parallel is usually good if you have the need for raw cpu computing power, like calculations of some sort, examples could be a 3D renderer, or I don't know, cracking hashes etc. not i/o work.

I/O work is usually more about orchestration than raw cpu power. Slow responses will not be solved by parallel computing a slow response is always a slow response. You will just consume more resources to no good.

This is the reason why just regular flatMap Is so powerful in reactor.

It will perform everything async for you without needing to deal with threads, locks, synchronization, joins etc. It will perform all work async as quick as possible utilizing as few resources as possible.

Answered By - Toerktumlare