Slightly off topic, but I have been testing various components, among them
XSL processors.
I found that the ASF processor (Xalan) was not the fastest, Saxon being
about 30% faster, but it was the most robust: ie, it continued to result in
no error at any load, whereas Saxon frequently caused errors when stressed.
I have run Tomcat with 20 concurrent users calling very db-intensive pages
(built via xsl, which is not currently particularly efficient, I think) for
24 hours without error or memory leak.
My feeling is that 3.2.1 is robust, but not the fastest. Which is probably
better than the other way round :-).
Alistair
-----Original Message-----
From: Todd Carmichael [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 02, 2001 4:14 PM
To: '[EMAIL PROTECTED]'
Subject: RE: performance
My tests, using Microsofts Web Application Stress (WAS) Tool, had the
following results for a simple servlet that all it did was display a single
html table:
Weblogic: 490 requests/sec
Tomcat: 540 requests/sec
Resin: 850 requests/sec - produced numerous socket errors (Connection reset
by peer). The other servlet engines did not do this.
This was on a Pentium III 600 Mhz with a heap of 128mb. I had 4 WAS (HTTP)
clients engaged in the tests. Each client had 50 threads hitting the Web
server
The real question being asked is Tomcat suitable for production
environments. This is something I really would like to get a feel for from
other developers experiences. I am very interested in using Tomcat for
production and the performance seems reasonable enough for me. I am curious
about monitoring tools and security issues with open source; that is what
our IT department will hammer us on.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 02, 2001 7:56 AM
To: [EMAIL PROTECTED]
Subject: RE: performance
Tomcat does indeed "catch up" if I stop the jmeter client, accessing the
application through a browser is much more responsive, but still a little
slower than I would hope. The same test with resin does not show any
noticeable degradation in performance. In fact I upped the ante with resin.
I started 2 more jmeter clients (configured the same), and still noticed no
significant drop in performance when accessing the site through a browser. A
few connections were refused, but that is to be expected, with the current
configuration.
You may ask, why not just use resin and stop whining :) ... in short while
resin does perform it has some problems in how it implements the servlet
spec that make me leery of deploying a production app on it.
Once again, any insight would be appreciated.
p.s. Randy,
Thanks for the info, I will check into the things that you mentioned. With
regards to the fingers, they are hard to come by, but I heard amazon.com is
opening a new branch and offering extremely discounted server fingers .. you
may want to check there :)
Thanks,
Bob
-----Original Message-----
From: Randy Layman [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 02, 2001 9:30 AM
To: [EMAIL PROTECTED]
Subject: RE: performance
I thought about what the delay probably meant after I sent the
message, but the message was already sent by then.
Back to the orginal problem or the performance.... Other people
have reported similar problems under "high" load. No one have ever really
given a definition of what high is since it depends upon your application,
however I would think that 20 concurent users should be completely supported
by Tomcat (our application does it).
Two things to note:
1. People who have reported these issuses usually say that if the
requests stop, Tomcat will eventually catch up
2. You might want to check whether or not its your application.
Try the same test, but request a small static file. This will show you what
the best performance you could hope to get. There were a few messages about
a week or two ago about tuning Tomcat, you might want to look at that,
although there wasn't much there. Another thing is you might look throught
the source and see where they initalize the thread pool (probably in
PoolTcpConnectors). Uping this size should give you more concurrent users,
however it will add more overhead when the server is idle. While you're
running your test, keep an eye on your network bandwidth usage and cpu
utilization. Its possible that you might be saturating the network (are the
responses very large?) or that you are only using one of your 4 processors
(I have no idea how to fix this).
Randy
PS Bob - where can I get some more fingers for my system? It needs to count
to 2.
-----Original Message-----
From: Steve Ruby [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 01, 2001 6:08 PM
To: [EMAIL PROTECTED]
Subject: Re: performance
That math didn't really work with JMeter anyway... even if you did
have 20 threads with 1ms delay, you don't get 20,000 request/sec. Jmeter
starts up 20 threads which each make a GET request to the server
but each thread only makes another request after it receives an answer
then it waits 1ms or 100ms whatever you have it sent to... So if none
of the threads get an ansewr then you have 0 requests/sec after they
are all tied up.
[EMAIL PROTECTED] wrote:
>
> Sorry, that was a typo. Jmeter is configured with a 100 ms delay, 20
threads
> :) , although the story is pretty much the same even with a 1000 ms delay.
>
> ( p.s. I also added an extra couple of fingers to the server so it could
> count higher ;) )
>
> Bob
>
> -----Original Message-----
> From: Randy Layman [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, February 01, 2001 3:50 PM
> To: [EMAIL PROTECTED]
> Subject: RE: performance
>
> Light load? It looks to me that you are sending
> 1ms * 1000 ms/s * 20 threads = 20,000 requests per second to the
> server. This would translate to 20K request/second * 60 seconds/min * 60
> minutes/hour = 72,000,000 request per hour. Maybe I'm not understanding
the
> numbers you quote (I'm not familary with JMeter), but I would be suprised
if
> any non-clustered web server running on Intel hardware could handle 72
> million hits per hour.
>
> (Although I would also be suprised if a Microsoft operating system
> could count to 72 million ;) )
>
> Randy
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, February 01, 2001 4:12 PM
> To: [EMAIL PROTECTED]
> Subject: performance
>
> Hi,
>
> I know that Tomcat does not claim to strive for the performance
> characteristics of other servlet containers, such as resin. However, I am
> wondering just how bad the performance is. I have run some tests, and I
have
> been a bit surprised.
>
> Test environment is a 4 proc NT server with 1 gig of memory. I am using
> tomcat 3.2.1 running standalone, and have set the max heap size for the
JVM
> to be about half of physical memory, also I have the server hotspot jit
> installed.. Additionally I am using Jmeter to apply some load.
>
> With 1 Jmeter client configured with a standard delay of 1 ms and 20
> threads, the website being hit becomes essentially non-responsive. Using
the
> same configuration, but substituting resin for tomcat, shows no noticeable
> degradation in performance.
>
> Again, I am not surprised that resin performs better, but I am surprised
> that Tomcat is that much slower, with even a light load applied.
>
> Are these performance characteristics to be expected. Does these results
> surprise anyone.
>
> Any feedback would be appreciated, and thanks in advance.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
