Jetty's SelectChannelConnector can manage ~200K connected clients fairly easily. You can use Jetty's continuations API (or the equivalent in Servlet 3.0 w/ Jetty 8+) to allow idle connections to be parked efficiently.
This is what CometD does, and it's currently handling ~100K connected clients in production at Yammer. (It's also worth noting that even a thread-per-connection model on a modern Linux system with a large heap can handle hundreds of thousands of concurrent connections. It's less memory efficient, but it's still very doable.) On Thu, May 24, 2012 at 2:32 PM, Otis Gospodnetic <[email protected]> wrote: > Thanks Simone, > > I think Vert.x has more than just a spike of tweets, though :) > > What I'm after is something that can handle a high number of concurrent > connections from an HTTP client (e.g. Apache HttpClient) to an HTTP server > (Jetty?). You can see in my sig why I'm interested in this.... > > Thanks, > Otis > ---- > Performance Monitoring for Solr / ElasticSearch / HBase - > http://sematext.com/spm > > > > > ----- Original Message ----- >> From: Simone Bordet <[email protected]> >> To: Otis Gospodnetic <[email protected]>; JETTY user mailing list >> <[email protected]> >> Cc: >> Sent: Thursday, May 24, 2012 5:16 PM >> Subject: Re: [jetty-users] Vert.x-like functionality in Jetty? >> >> Hi, >> >> On Thu, May 24, 2012 at 8:59 PM, Otis Gospodnetic >> <[email protected]> wrote: >>> Hi, >>> >>> Are you saying CometD provides the same scalability and concurrency Vert.x >>> claims to provide? >> >> Look carefully at the Vert.x benchmark: they open 6 (six) connections >> and pipeline on each 2000 requests. >> How realistic is such traffic ? >> >> I am sure Vert.x 1.0 is a fine framework and all that, but I'd like to >> see a more realistic benchmark before expressing an opinion. >> That is what we tried to achieve with the CometD benchmark, which >> implements a chat application, with 1k, 5k 10k up to 200k connected >> users to a single server and different message rates. >> >>> If CometD provides (and has been providing for years) the high scalability >>> and concurrency support, what's all Vert.x all about? >> >> Ask them :) >> To me, it's about diversity. >> Why there exist more than one servlet container ? >> >>> Is it the case that >>> while CometD may provide the same stuff Vert.x does, CometD is not widely >>> known or is at least not as popular? (if so, that can be critical for its >>> future) >> >> Not sure what Vert.x provides yet (have not looked in details), but >> CometD provides authentication hooks, fine-grained access control, >> message acknowledgment and guaranteed server-to-client message >> delivery on short network failures, a fully extensible framework, >> transport independence and fallback, automatic reconnections, and I >> can continue for a while. >> >> I heard about Vert.x one month or less ago, actually, so I personally >> do not classify it as "popular" just because it had a spike in tweets. >> >> Evaluate both frameworks and choose the one that fits your case better. >> >> You have not said what is it in Vert.x that appeals you. It's just the >> benchmark result ? >> >> Simon >> -- >> http://cometd.org >> http://intalio.com >> http://bordet.blogspot.com >> ---- >> Finally, no matter how good the architecture and design are, >> to deliver bug-free software with optimal performance and reliability, >> the implementation technique must be flawless. Victoria Livschitz >> > _______________________________________________ > jetty-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/jetty-users -- Coda Hale http://codahale.com _______________________________________________ jetty-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/jetty-users
