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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
