tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "brien colwell" <xcolw...@gmail.com>
Subject Re: max number of concurrent requests
Date Mon, 17 Dec 2007 00:49:10 GMT
hi Christophe,

Comet seems like it's addressing the issues I have ... it looks like it is
implemented with a fixed-size pool of active threads, each dispatching
events to what could be an unbounded number of listeners ...  I'm going to
try a scale test with Comet and report back ...

Stepping back, the number of long lived HTTP connections seems bounded by
only the number of concurrent TCP/IP connections supported.  I'm not sure
how Comet determines whether there is new data on a socket, but it seems
this could be done on a single thread. That is, using
asynchronous/non-blocking sockets.

My requirements are actually a bit less than what Comet appears to support.
My protocol requires the client to send data only in the beginning of a
session ... I might be able to use that to get more performance out of the
framework ...

Thanks,
Brien

On Dec 16, 2007 12:34 PM, Christophe Pierret <cpierret@sparus-software.com>
wrote:

> Brien,
> Depending on the HTTP connector you use (may be basic HTTP, APR or NIO)
> and whether you use the comet API or not, the limit to number of maximum
> concurrent long-lived connections in tomcat may be very different.
> In my experience, the most scalable is with:
> 1) NIO + comet or APR + comet
> 2) APR or NIO without comet
> 3) standard HTTP connector
>
> The OS you are running onto has also an impact.
> For example, with standart HTTP connector (default one) on a Linux Red Hat
> 4 , dual cpu box with 2Gb of RAM (under VMWare), we managed to run a
> successful 3000 concurrent HTTP requests (long running HTTP requests) at a
> customer site. The same box under Windows was behind, but it may due to our
> inability to tune it?
> We had to tune the linux system and the JVM to reach those numbers, but
> your load may differ from that of our application and you may get very
> different numbers: plan some testing ahead ...
> The system limits you usually bump into:
> 1) max number of threads per process
> 2) max memory per process (use java option -Xss to reduce thread stack
> size and -Xmx to up the java heap size, tune the corresponding system limit)
> 3) max file descriptors per process
> There are many others that I don't have at the top of my mind right now...
> Type "man ulimit" at your linux prompt to get some more hints.
>
> Using comet + NIO or APR, you may break these barriers by not using one
> thread per long-lived request.
>
> I hope this helps and points you to some area of research.
>
> Best regards,
> Christophe Pierret
>
> -----Message d'origine-----
> De: brien colwell [mailto:xcolwell@gmail.com]
> Envoyé: samedi 1 décembre 2007 23:23
> À: dev@tomcat.apache.org
> Objet: max number of concurrent requests
>
> hi all,
>
> I'm building a framework that needs to block on HTTP requests. That is,
> at some point when executing my servlet, the thread will wait for some
> event to happen. Of course this wait may be very long. Is there a limit
> to threads in Tomcat? Is there a mechanism to yield processing a
> request, and then pick it up later?
>
> Sorry if this is unclear ...
>
> Thanks,
> Brien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message