Testing project Loom for long-running background jobs

[Ron Pressler]

Hi, and thank you for evaluating Loom.

There are different measures of performance. Latency is how fast — i.e. at what
duration — you can do a certain task. Throughput is the rate of tasks you can
perform. Virtual threads improve throughput, thanks to Little’s law, by letting 
the applications do more things at once. Put simply, it can increase application
throughput by reducing the cost, including memory footprint, required by threads. 
See more about this in [1].

Virtual threads do not improve latency, at least not by a big amount. If you  
have a certain fixed amount of work to do, virtual threads won't help you do it
faster (they can help you do more work, though). In addition, due to OS
limitations, virtual threads are particularly limited in how much help they can
give when filesystem IO is concerned.

In short: if you have a small number of tasks, and especially if most of what  
they do is disk IO, virtual threads are not expected, nor are they intended, to
improve your application’s latency.

[1]: https://inside.java/2020/08/07/loom-performance/  

— Ron


On 21 August 2020 at 16:28:59, Ronald Dehuysser (ronald.dehuysser at gmail.com(mailto:ronald.dehuysser at gmail.com)) wrote:

> Dear dev's,
>  
> I tested project Loom for JobRunr (https://github.com/jobrunr/jobrunr) and
> I've written down the results in a blog post:
> https://www.jobrunr.io/blog/project-loom-virtual-threads-and-jobrunr/
>  
> I'm seeing a lot of improvements memory wise but not performance wise. Is
> this expected?
>  
> During my tests quite some I/O happens (to an SSD disk/ no http/tcp calls
> though) but I limit the work to 128 virtualThreads in parallel. Is there
> any other tuning I can do to increase performance?
>  
> My feedback to you: the transition to Virtual Threads was really easy and I
> did not run into trouble, nice work! I did have one JVM crash though.
>  
> Kind regards and looking forward to your feedback,
> Ronald