Rajeev Jha schrieb:
Tp wrote:
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.
You can try jetty 6 also [ if you are not very particular about using
tomcat ] . Jetty 6 Continuations can help you do a suspend/resume of
request. so a thread is not blocked due to idle wait and you can
multiplex more connections on less threads.
Hi Rajeev, that sound like a possible solution. Is jetty written purely
in java and if so do they use nio? How can I suspend/resume processing
of requests in jetty? Multiplexing would definelty increase the
perfomance, since I would save one thread per connection.
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.
requests/second can be misleading in this case. what you want to know is
"# open connections vs. latency for user".
yours,
Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]