4 ms·
I've messed with async on JVM. In my experience, it doubles speed at most for CRUD apps with heavy DB access. Async is only useful if you're thread starved, and
by thermodynthrway 8y ago
I've messed with async on JVM. In my experience, it doubles speed at most for CRUD apps with heavy DB access. Async is only useful if you're thread starved, and most DB calls are fast enough that it never happens.
The one place it makes a huge difference is when you're waiting on other, possibly slow, services like third party REST calls. If you have 100 threads and each call takes 1000ms you will run out of threads at 100 req/sec which is quite low for the JVM.
Using async in these situations allows thousands of threads to be paused while your 100 still do work, allowing you to handle maybe 10k req/sec even with a slow partner service.
A lot of JS programmers don't understand the relation between thread starvation and async, they act like async is magic. If you're not thread starved (everything you do is pretty quick) then async is useless
- apta 8y ago> I've messed with async on JVM. What library or framework did you use? Using ExecutorService or similar would still have those 100 threads blocked even if they run in their own future, correct? The only thing it would allow is queuing the other incoming requests, but it does not time slice or switch to another request upon hitting an IO request.
- thermodynthrway 8y agoYou can use fiber libraries like quasaras your executor, just like Go uses for regular threading. The double edged sword of Java is that you can do anything. But the learning curve is huge because there's so much crap out there