+1 As usual it depends highly how well your app is written and where your bottleneck is.
On a project, our very poorly-written Tomcat app was failing at ~50 concurrent users. BUT it was always because of the Oracle DB being starved on its 4 cores - 8GB of RAM machine. :-( On another project, we've written an app without any real concern for scalability at coding-time and it was easily able to accept ~2000 concurrent users on each of our 8 cores - 32GB of RAM machines on an ISP connection. It was more than asked, so we didn't try to benchmark the app more than that. But it was without any doubt and from the very beginning a better skilled team. So your mileage may vary and I'd advise to try and benchmark it using a load-testing tool. Regards, Pierre On Thu, Jan 7, 2010 at 9:40 PM, Leon Rosenberg < rosenberg.l...@googlemail.com> wrote: > of course there can't be a high-load thread without me, so here are my 2 > cents: > > <2 cents> > I'm working in high-performance high-portal environment since 2004, > and i must say that starting with tomcat 5 > i've never experienced any performance problems caused by tomcat itself. > The number of concurrent users and, more important, concurrent > requests on a tomcat instance are limited by your network bandwidth, > your cpu, your ram and, first of all, your application but not tomcat. > My largest installation served more than 30.000 concurrent users, > which produced about 4.000 requests per second (cumulated over few > machines) all well under 500 ms delivery time. However the application > was optimized for performance and scaleability. > So, with 95% certainty your problem won't be tomcat! :-) > Go for the kitty ;-) > </2cents> > > regards > Leon > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Ad augusta per angusta Des résultats grandioses par des voies étroites
