CODEWITHSUNDEEP
scala
d-_-b
d-_-b

Reputation: 4502

Are there any differences in performance between non-blocking IO request and blocking IO request wrapped in Future?

Suppose that Play framework is used, are these methods effectively the same in terms of performance?

def requestA(): Future[Response] = Future {
  blockingIoRequest()
}


def requestB(): Future[Response] = {
  nonBlockingIoRequest()
}

Upvotes: 0

Views: 85

Answers (2)

Ivan Kurchenko
Ivan Kurchenko

Reputation: 4063

In case you described, it depends more on the fact which ExecutionContext you use, then blocking or non blocking operation you invoke.

Basically, if in case of 

def requestA(): Future[Response] = Future {
  blockingIoRequest()
}

you will use same ExecutionContext which is used in controllers (for instance for Action.async handling), Filters or other request handling places, then yes - it will impact performance, because blocking the thread inside such Future execution, will impact other incoming request handling. Hence, it is recommended to perform such blocking operations inside another ExecutionContext intended to be used for blocking operation (like DB access, network operations etc.)

Please, take a look for more details at doc page: https://www.playframework.com/documentation/2.8.x/ThreadPools

Hope this helps!

Upvotes: 1

Anand Sai
Anand Sai

Reputation: 1586

I think:

  • using blocking requests means that only one request may be active at any time in any one thread (because it blocks while waiting for activity)
  • using blocking requests is generally easier than non-blocking requests (asynchronous programming tends to be more complicated)
  • you could create 1 thread per request but threads have overhead and are extremely inefficient compared to the non-blocking solutions;
  • non-blocking requests could handle a much larger volume of requests: it could scale to hundreds of thousands in a single process - but the code becomes a little bit more complicated

Nonblocking I/O will give you the best performance (thousands of requests) at the expense of being the most difficult to understand and implement correctly.

Basically everything boils down to performance vs. programming complexity.

Let me know if it helps!!

Upvotes: 1

Related Questions