I have also tested IBM¡¦s JDK 1.3 and my test case had many CPU intense jobs
(processor loading was > 90%). I found that IBM¡¦s JDK only took 13sec to
complete all the jobs while SUN¡¦s required 20 sec to complete.
FYI
Kenneth
-----Original Message-----
From: Todd Carmichael [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 06, 2001 4:12 AM
To: '[EMAIL PROTECTED]'
Subject: RE: performance
IBM does have a 1.3 for Intel and it is quite fast (faster than
sun's
hotspot in my tests).
(You need to register with IBM to get in.
http://www6.software.ibm.com/dl/wspt/priv/wspt-h?S_PKG=pretechww
-----Original Message-----
From: John Golubenko [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 05, 2001 7:59 AM
To: [EMAIL PROTECTED]
Subject: Re: performance
It's true.
>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
On 2/2/01, 5:45:09 PM, "Geoff Lane" <[EMAIL PROTECTED]> wrote
regarding
Re: performance:
> I think it's only for Linux (and AIX) - good reason to switch. :)
> More info is available at: http://www.alphaworks.ibm.com/tech
> Todd Carmichael wrote:
> >
> > Running Windows 2000 Advanced Server with Sun JDK 1.3 and
hotspot.
> >
> > Anyone know where can I find the IBM JDK 1.3 for Windows
platforms?
> >
> > -----Original Message-----
> > From: Steve Ruby [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, February 02, 2001 2:15 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: performance
> >
> > With tomcat 3.2.1 and IBM JDK1.3 on linux
> >
> > running a PII 400Mhz with 192Megs (physical) I was able toget
> >
> > 650 requests/sec
> >
> > running apache ab like this
> > -n 10000 -c 100
> > against the RequestInfo example servlet. with no un-returned
requests.
> >
> > Which JVM/OS where you running in the tests below?
> >
> > Todd Carmichael wrote:
> > >
> > > 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]
org
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
[EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
org
> --
> Geoff Lane <[EMAIL PROTECTED]>
> (650) 969-5000 x104
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email:
[EMAIL PROTECTED]
NOTICE: This communication may contain confidential or other
privileged
information. If you are not the intended recipient, or believe that
you
have received this communication in error, please do not print,
copy,
retransmit, disseminate, or otherwise use the information. Also,
please
indicate to the sender that you have received this email in error,
and
delete the copy you received. Any communication that does not
relate to
official Columbia business is that of the sender and is neither
given nor
endorsed by Columbia. Thank you.
---------------------------------------------------------------------
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]
