Thanks, Sergey, yes, I'm actually using callbacks here, but looks like they don't require the async transport. The regular one (cxf-rt-transports-http) also works fine and shows similar (or even better) performance.
I debugged it further and noticed that the regular (non-async) transport always creates 24 workqueue threads to execute the requests. I modified the test so that the server now has a 5-second delay and the client only sends 75 concurrent requests. Somehow the non-async transport managed to initiate all 75 requests at the same time using only 24 threads! And they all completed in 5.7 seconds. How is that possible? Does it actually somehow use NIO under the hood? I also saw this <http://cxf.547215.n5.nabble.com/Async-http-client-experiments-td5711683.html> threadby Daniel Kulp where he got 4x performance improvement by using the async transport (from 35 seconds down to 9 seconds). But in my experiments they are almost the same. Or maybe the regular transport became more efficient since 2012? -- View this message in context: http://cxf.547215.n5.nabble.com/Async-transport-performance-using-cxf-rt-transports-http-hc-tp5751832p5751876.html Sent from the cxf-user mailing list archive at Nabble.com.
