[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Vert.x-like functionality in Jetty?

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
<otis_gospodnetic@xxxxxxxxx> 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 <sbordet@xxxxxxxxxxx>
>> To: Otis Gospodnetic <otis_gospodnetic@xxxxxxxxx>; JETTY user mailing list <jetty-users@xxxxxxxxxxx>
>> 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
>> <otis_gospodnetic@xxxxxxxxx> 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
> jetty-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jetty-users



-- 
Coda Hale
http://codahale.com