Infinitely scalable microservices with Project Loom and Helidon
summary
Shows an experimental integration of Project Loom (early‑access JDK 16 virtual threads) with Helidon MP, swapping Helidon’s thread manager with three changed files. Test app sleeps (default 100ms); load tool Vegeta runs 1000 rps for 10s. Traditional setup rises from 8 to 32 OS threads and sees ~8s max latency with many >2s; Loom run uses ~7 OS workers, max latency <200ms and ~94–95% responses <100ms. Code impact is minimal.
AI-written summary · about
chapters (18)
- 0:00Intro
- 1:12What is Project Loom?
- 1:48Why Project Loom?
- 3:49Threads for better scalability
- 7:24Problem: Blocking calls
- 10:55How to solve? Application based solution: Reactive/Asynchronous
- 13:51Development based solution requires you to choose between
- 15:13Platform based solution: Fiber (Lightweight/Virtual/Green Thread)
- 17:43Helidon Architecture
- 23:18Build Profiles
- 26:30Code changes
- 27:05Get JDK with Loom
- 27:40Test application
- 28:06Test scenario and tools
- 30:108 (initial - default) Native threads - AFTER TEST
- 31:12Virtual threads - BEFORE TEST
- 31:53Scenario 2: Virtual threads - AFTER TEST Fork
- 34:13Conclusion
related talks
36mHelidon on Loom
41mHelidon - Microservices on Modern Java
44mVirtual Threads in Action!
01h 13mProject loom: Modern scalable concurrency for the Java platform
54mLooming in the cores
39mProject Loom: Modern Scalable Concurrency for the Java Platform
38mJava Project Loom: Why Should I Care?
31mJava Virtual Threads