Hi Tim, On 4/14/07, Kimmet, Tim <[EMAIL PROTECTED]> wrote:
Does Jakarta Commons HttpClient support async i/o? If not, then wouldn't a MINA-based client (that would support async i/o) offer a good advantage because less threads would be required to process each http request?
Yes. You might also be interested in Apache Jakarta HttpComponent project: http://jakarta.apache.org/httpcomponents/index.html I didn't look into the asynchronous part yet though.
Let's also take this one step further and think about even larger benefits... Let's say I wanted to use AsyncWeb to host a service that spends most of its time doing HTTP calls to a 3rd-party-service. Let's say the total request time in the AsyncWeb service is 110 millis, but the HTTP-call to the 3rd-party-service takes 100 millis. I would think that AsyncWeb + MINA-Http-Client would provide huge benefits in this scenario because the whole request/response lifecycle and 3rd-party-service call to the back-end would be totally async. That is, in a typical Java Servlet model (without async i/o) using the Jakarta Commons HttpClient (I don't think it supports async i/o) would require MANY more threads to support the same throughput as AsyncWeb + MINA-HTTP-Client in a totally i/o-bound service. In addition, manageability is difficult in the typical Servlet model because in the Servlet model you'd have to increase the threads in HttpClient when you increase threads in the Servlet container thread pool. Thoughts?
With modern operating system with O(1) scheduler, the number of thread won't affect the performance much. I think it highly depends on the number of connections. Blocking I/O can perform better than NIO with about 2000~3000 threads. Anyways, it's true that NIO will outperform eventually. The actual problems of blocking I/O are 1) that too many threads can make debugging very difficult and 2) that the service with many keep-alive connections can go out-of-service just because the thread pool is exhausted even if the server is actually idle and it leads huge irrational thread pool size (i.e. 30000). I gave a presentation about this topic recently in Korea: http://www.gleamynode.net/BCSeoul2006.pdf It's written in Korean, but it might help. :) HTH, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
