On Sun, 2006-08-27 at 14:18 -0700, Tatu Saloranta wrote: > -- Roland Weber <[EMAIL PROTECTED]> wrote: > > > Hi Oleg, > > > > > At this point of time I tend to think NIO on the > > client side makes no > > > sense at all, as it makes little sense for an HTTP > > client to keep > > > hundreds of connections open. > > > > I agree. Server-side use will also be confined to > > Actually, I think there are cases where this is not > true: specifically, when server itself has to act as a > client towards other systems. This is typically the > way web services work: there are multiple layers of > services, depending on other backend services. > So, a server acting as a client may easily need to > keep thousands of (usually high latency) connections > open simultaneously > > And this is the specific case where NIO would be > necessary for scalability: it doesn't help if server > side can handle thousands of client-facing > connections, if it can't serve those due to > limitations with its own access-as-client. > > In fact, this is the main reason why I am very > interested in HttpCore/HttpClient developments: for > server-side NIO there are solutions, but for > client-side there aren't. > > Anyway, just my 2c, > > -+ Tatu +- >
Hi Tatu, I respectfully remain unconvinced. The problem is not the blocking I/O as such, but rather the one thread per connection model, which is often (mis)used due to its simplicity. I personally think that the platform you have described, which is essentially an HTTP proxy, may perform better using a reasonably sized thread pool, blocking I/O connections and carefully chosen connection keep-alive strategy. NIO _may_ provide more advantageous only if most of those connections constantly generate some fair amount of traffic at a very low rate thus infinitely blocking worker threads and preventing them from being efficiently reused. At the same time asynchronous HTTP transport may easily succumb to the same problem when using a dedicated worker thread per HTTP request / HTTP connection. I am putting final touches on the asynchronous NIO transport for HttpCore and planning to run some performance benchmarks of HttpCore vs HttpCore NIO vs HttpCore on MINA vs AsyncWeb. I expect HttpCore to win by a healthy margin, but I may be wrong. I was not planning to write a client side non-blocking NIO transport but since this topic comes up with depressing regularity and will probably reconsider just to prove my point and demonstrate flexibility of HttpCore. Cheers Oleg > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
