java - More connections than thread handlers -
say have 2 endpoints in api (in spring previously):
@requestmapping("/async") public completablefuture<string> g(){ completablefuture<string> f = new completablefuture<>(); f.runasync(() -> { try { thread.sleep(5000); f.complete("finished"); } catch (interruptedexception e) { e.printstacktrace(); } }); thread.sleep(1000); return f; } @requestmapping("/sync") public string h() throws interruptedexception { thread.sleep(5000); thread.sleep(1000); return "finished"; }
when send 2 requests (just single requests) to:
localhost:8080/async
--> response in 5024ms
localhost:8080/sync
--> response in '6055ms`
this makes sense because sending single request. things interesting when load test siege involving 255 concurrent users.
in case, async
api endpoint isn't able handle many connections.
so async
not scalable.
does depend on hardware? had hardware able handle more thread-handlers, heavy hardware, async 1 able handle more transactions since there more threads?
you're still using forkjoinpool.commonpool()
async invocations. told it's small , filled up. try (i fixed completablefuture
code too, it's totally wrong, doesn't show in example).
completablefuture<void> f = completablefuture.runasync(() -> { try { thread.sleep(5000); } catch (interruptedexception e) { e.printstacktrace(); } }, executors.newsinglethreadexecutor()); return f;
now each async call gets own executor, doesn't choke on common pool. of course since async calls own executor, bad example. you'd want use shared pool, larger common pool.
it has nothing (well, little) hardware. has long running operations intermingled short running operations.
Comments
Post a Comment