tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Delbecq <>
Subject Re: Rephrased: Maximum number of simultaneous HTTP connections
Date Mon, 03 Apr 2006 10:36:08 GMT
Tp a écrit :

> Hi,
> we have to develop a high performance chat based only on HTML and HTTP
> only for a television company. The chat's output window requires one
> open HTTP connection per client, which means that you need at least
> 3000 simultaneous ie. open HTTP connections for 3000 chatters.
> To the former post people replied that HTTP in combination with the
> Servlet API is not made for this. The basic problem is that you a.)
> run out of connections and b.) out of threads after a while. The
> servlet API of Tomcat dedicates one Thread to each connection, which
> is particular bad.

If you don't like it, complain to sun about their j2ee specs. In my
point of view, this is really good as it guarantee context isolation of
requests for application writer.

> And there seems to be no workaround, because the connection will close
> after the doGet() and doPost() method finishes (is that actually
> true?). So, the only way to keep 3000 simultaneous connections is to
> keep 3000 of those methods from returning, wehich means keeping 3000
> threads busy.
> So I guess my question is: How many TCP connections can be created on
> a single machine using Java and then how many threads can be created
> so that application still responds? I assume that the machine runs on
> a Pentium 4 3.2 Ghz with 1 GB of RAM under linux and that all the file
> descriptor limits are set to the maximum.

I think i already answered you in my previous mail. The answer is...

> Can anybody give me some Hardware and Software recommendations on a
> Java Application sever, which can handle up to 3000 simultaneous HTTP
> connections and still respond?
> I know for example that BEA and JRun are very performant, but
> unfortuantely BEA is to expensive and then Macromedia only talks about
> the HTTP requests per second in their benchmarking tests, which is
> very different from what I'm asking.
> yours,
> Tim
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message