Sunday, November 24, 2013

Situations when you must not forget to use the scala blocking statement when working with futures...

Futures imply the use of an execution context, a custom one or the default one. An execution context is a mechanism that manage threads for you, map operations to be executed on them, they come with internal default limits which are most of time proportional to the number of CPU you have. This default behavior is the right one when dealing with CPU consuming operations, but with IO this is not the case. If you need to call 100 remote calls (1 seconds required for each of them) on an other system and you have only 2 cpu, your total response time will be 50 seconds, for an almost 0% cpu usage on your host...

That's why the blocking statement was introduced, it allows you to mark a code section as blocking, by blocking we mean time consuming and not cpu consuming. Thanks to this statement, the execution context will be able to grow as necessary, and you'll get very low latency.

On my 6 cores CPU, 50 virtual remote calls (2 seconds for each call) require only 2056ms with the blocking statement, and it requires of course 18 seconds without it (18s * 6cpu = 108s * 1cpu).

Take care with Futures created in scala for-comprehension...

Create Futures outside the for-comprehension, in order for them to start immediately their operations. If you create your futures inside the for-comprehension, your execution will be sequential and not concurrent ! This is a mistake very easy to make, not so easy to detect because it won't fail, you just won't be able to use all your CPU as you should when the processing involves CPU, or for other cases check for example how many network connections are established simultaneously...