Some good advice in this thread already, but given the power of server there
should be no problem serving even more requests ( as long as they are small,
not bound by CPU or I/O).
I'd start looking at JVM GC properties.
Turn on gc logging with
-Xloggc:/someplace/gclog_tomcat.txt
From: Darius D. [mailto:darius@gmail.com]
Subject: Re: Performance for many small requests
in my opinion using 64bit JVM with such a small
heap is only needed if performance testing shows
gains versus 32bit JVM.
The main advantage of using a 64-bit JVM is the increased number
n828cl wrote:
From: Darius D. [mailto:darius@gmail.com]
Subject: Re: Performance for many small requests
in my opinion using 64bit JVM with such a small
heap is only needed if performance testing shows
gains versus 32bit JVM.
The main advantage of using a 64-bit JVM
On 9/3/2011 1:15 PM, Darius D. wrote:
n828cl wrote:
From: Darius D. [mailto:darius@gmail.com]
Subject: Re: Performance for many small requests
in my opinion using 64bit JVM with such a small
heap is only needed if performance testing shows
gains versus 32bit JVM.
The main advantage
David Kerber wrote:
On 9/3/2011 1:15 PM, Darius D. wrote:
n828cl wrote:
From: Darius D. [mailto:darius@gmail.com]
Subject: Re: Performance for many small requests
in my opinion using 64bit JVM with such a small
heap is only needed if performance testing shows
gains versus 32bit
From: David Kerber [mailto:dcker...@verizon.net]
Subject: Re: Performance for many small requests
Then why shouldn't I just double my heap size? Wouldn't
that eliminate the risk of increased cache misses?
As Darius stated, this part of the discussion is probably completely irrelevant
-Original Message-
From: Darius D. [mailto:darius@gmail.com]
Sent: Saturday, September 03, 2011 1:36 PM
As a side note - (CPU)cache/TLB misses have nothing to do with heap size.
Too big heap size can be as bad as too low ( by stealing memory from OS that
could
have been used
Jeff Sturm wrote:
The Linux JVM has a nice option -XX:+UseLargePages to help avoid TLB
misses on heap accesses. It's good for modest gains, and has the side
effect of locking the heap into memory. I tend to use it on systems with
large heaps.
Not much you can do about cache misses
On 8/31/2011 12:25 PM, Tony Anecito wrote:
Hi David,
You need to not only look at the container but it's configuration and the jre
that is being used. There have been a lot of improvements in all areas for
performance. Also, understand the servlet model seems developers have
completely
kerber dcker...@verizon.net
Subject: Re: Performance for many small requests
To: Tomcat Users List users@tomcat.apache.org
Date: Thursday, September 1, 2011, 8:40 AM
On 8/31/2011 12:25 PM, Tony Anecito
wrote:
Hi David,
You need to not only look at the container but it's
configuration
On 01/09/2011 15:40, David kerber wrote:
On 8/31/2011 12:25 PM, Tony Anecito wrote:
Hi David,
You need to not only look at the container but it's configuration and
the jre that is being used. There have been a lot of improvements in
all areas for performance. Also, understand the servlet
integrity checks and write
it to disk, then returns an ok response to the client.
Regards,
-Tony
--- On Thu, 9/1/11, David kerberdcker...@verizon.net wrote:
From: David kerberdcker...@verizon.net
Subject: Re: Performance for many small requests
To: Tomcat Users Listusers@tomcat.apache.org
Date
From: David kerber [mailto:dcker...@verizon.net]
Subject: Re: Performance for many small requests
Are you using 64-bit java or 32-bit?
64-bit.
Might want to try -XX:+UseCompressedOops, since you have a small heap on a
64-bit JVM.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL
On 9/1/2011 11:36 AM, Caldarale, Charles R wrote:
From: David kerber [mailto:dcker...@verizon.net]
Subject: Re: Performance for many small requests
Are you using 64-bit java or 32-bit?
64-bit.
Might want to try -XX:+UseCompressedOops, since you have a small heap on a
64-bit JVM.
I'll
From: David kerber [mailto:dcker...@verizon.net]
Subject: Re: Performance for many small requests
Is there any indication from what I've said that
I need a larger heap?
Don't think so, but GC logging will tell you for sure. The compressed OOPs
capability with a small heap should
and has to wait for disk IO unless it is spawned off to an independent thread.
Hope this helps.
-Tony
--- On Thu, 9/1/11, Caldarale, Charles R chuck.caldar...@unisys.com wrote:
From: Caldarale, Charles R chuck.caldar...@unisys.com
Subject: RE: Performance for many small requests
To: Tomcat
of performance tuning a couple of
years ago.
Hope this helps.
-Tony
--- On Thu, 9/1/11, Caldarale, Charles Rchuck.caldar...@unisys.com wrote:
From: Caldarale, Charles Rchuck.caldar...@unisys.com
Subject: RE: Performance for many small requests
To: Tomcat Users Listusers@tomcat.apache.org
Date
From: David kerber [mailto:dcker...@verizon.net]
Subject: Re: Performance for many small requests
For small requests having a large new generation in the heap helps.
This helps with the short term objects in the heap to get collected.
I'm not sure what this means, but I'll do some
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David,
On 9/1/2011 10:40 AM, David kerber wrote:
I'm having some somewhat minor performance issues, not performing
quite as well as my Win2k machine with TC 5.5. Could somebody look
at my server.xml and recommend some tweaks for handling tons of
On 9/1/2011 1:15 PM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David,
On 9/1/2011 10:40 AM, David kerber wrote:
I'm having some somewhat minor performance issues, not performing
quite as well as my Win2k machine with TC 5.5. Could somebody look
at my server.xml
From: David kerber [mailto:dcker...@verizon.net]
Subject: Re: Performance for many small requests
You could also use the NIO connector which allows you
to have fewer threads serve more requests without the
keepalive-expiration delay.
Thanks, I'll take a look at this.
NIO may incur
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chuck,
On 9/1/2011 2:00 PM, Caldarale, Charles R wrote:
From: David kerber [mailto:dcker...@verizon.net] Subject: Re:
Performance for many small requests
You could also use the NIO connector which allows you to have
fewer threads serve more
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Subject: Re: Performance for many small requests
NIO may incur slightly more overhead due to thread switching.
You'll have to measure to see if it's of any benefit.
Yes, but my guess is that it would be better than suffering
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chuck,
On 9/1/2011 4:52 PM, Caldarale, Charles R wrote:
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Subject: Re: Performance for many small requests
NIO may incur slightly more overhead due to thread switching.
You'll have
On 31/08/2011 15:11, David kerber wrote:
Has there been any comparison testing done in how the latest 7.x version
of TC will compare to the latest 6.0.x version, in the case of tons
(hundreds per second) of very small, quick-to-process requests?
Not that I am aware of.
I have a machine
On Wed, Aug 31, 2011 at 16:11, David kerber dcker...@verizon.net wrote:
Has there been any comparison testing done in how the latest 7.x version of
TC will compare to the latest 6.0.x version, in the case of tons (hundreds
per second) of very small, quick-to-process requests?
I have a machine
On 8/31/2011 10:18 AM, Francis GALIEGUE wrote:
On Wed, Aug 31, 2011 at 16:11, David kerberdcker...@verizon.net wrote:
Has there been any comparison testing done in how the latest 7.x version of
TC will compare to the latest 6.0.x version, in the case of tons (hundreds
per second) of very
On 8/31/2011 10:16 AM, Mark Thomas wrote:
On 31/08/2011 15:11, David kerber wrote:
Has there been any comparison testing done in how the latest 7.x version
of TC will compare to the latest 6.0.x version, in the case of tons
(hundreds per second) of very small, quick-to-process requests?
Not
JavaOne Outstanding Developer Award
--- On Wed, 8/31/11, David kerber dcker...@verizon.net wrote:
From: David kerber dcker...@verizon.net
Subject: Re: Performance for many small requests
To: Tomcat Users List users@tomcat.apache.org
Date: Wednesday, August 31, 2011, 8:22 AM
On 8/31/2011 10:18
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
All,
On 5/12/2009 9:38 AM, Caldarale, Charles R wrote:
Might be interesting to modify it to run with more cores, if you have
a system available.
Here are the results I got on two different systems. Note that I
compiled the test code using the 1.5
On Tue, May 12, 2009 at 6:27 AM, Caldarale, Charles R
chuck.caldar...@unisys.com wrote:
From: David Kerber [mailto:dcker...@verizon.net]
Subject: Re: Performance with many small requests
Incrementing a counter can't be much of a synchronization bottleneck,
and if I switch to an AtomicInteger
From: David Kerber [mailto:dcker...@verizon.net]
I definitely should hook a profiler to the app so I can be sure of
what's taking the time, though.
Yes. If you don't measure it, you don't know whether you're fixing the right
problem!
Also consider connector, then if necessary process and OS
Leon Rosenberg wrote:
On Tue, May 12, 2009 at 6:27 AM, Caldarale, Charles R
chuck.caldar...@unisys.com wrote:
From: David Kerber [mailto:dcker...@verizon.net]
Subject: Re: Performance with many small requests
Incrementing a counter can't be much of a synchronization bottleneck,
and if I
Peter Crowther wrote:
From: David Kerber [mailto:dcker...@verizon.net]
I definitely should hook a profiler to the app so I can be sure of
what's taking the time, though.
Yes. If you don't measure it, you don't know whether you're fixing the right
problem!
It was apparent early on
From: David kerber [mailto:dcker...@verizon.net]
In my original post, I posted a bunch of numbers about
network and other
possible bottlenecks, and what it boiled down to was that neither my
firewall load, nor total internet connection bandwidth were close to
their limits.
Thanks.
Peter Crowther wrote:
From: David kerber [mailto:dcker...@verizon.net]
In my original post, I posted a bunch of numbers about
network and other
possible bottlenecks, and what it boiled down to was that neither my
firewall load, nor total internet connection bandwidth were close to
their limits.
From: David kerber [mailto:dcker...@verizon.net]
Just over 1000 total, 810 to the port that this application is using.
Should be fine on Windows.
The vast majority are showing a status of TIME_WAIT, a dozen or so in
ESTABLISHED and one (I think) in FIN_WAIT_1.
Sounds fair enough. The
From: Peter Crowther [mailto:peter.crowt...@melandra.com]
Subject: RE: Performance with many small requests
That said, if a client has multiple data items to send in rapid
succession, does it accumulate those and batch them, or does it send
each one as a different request? Or does
Peter Crowther wrote:
From: David kerber [mailto:dcker...@verizon.net]
Just over 1000 total, 810 to the port that this application is using.
Should be fine on Windows.
That was my gut feeling too, but I'm glad to have it confirmed.
The vast majority are showing a status of
Caldarale, Charles R wrote:
From: Peter Crowther [mailto:peter.crowt...@melandra.com]
Subject: RE: Performance with many small requests
That said, if a client has multiple data items to send in rapid
succession, does it accumulate those and batch them, or does it send
each one as a different
From: David kerber [mailto:dcker...@verizon.net]
A typical client will have 2 to 5 items to send per
transaction (they're
actually lines from a data logger's data file), and each line
is done in
a separate POST request. The frequency of transactions varies widely,
but typically won't
From: Leon Rosenberg [mailto:rosenberg.l...@googlemail.com]
Subject: Re: Performance with many small requests
If you would share your test code, I would love to test it on
some *nixes and darwins I have here;
Here's the code I used to do the synch vs atomic testing. The command line
Caldarale, Charles R wrote:
From: Leon Rosenberg [mailto:rosenberg.l...@googlemail.com]
Subject: Re: Performance with many small requests
If you would share your test code, I would love to test it on
some *nixes and darwins I have here;
Here's the code I used to do the synch vs atomic
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chuck,
On 5/12/2009 12:27 AM, Caldarale, Charles R wrote:
From: David Kerber [mailto:dcker...@verizon.net]
Subject: Re: Performance with many small requests
Incrementing a counter can't be much of a synchronization bottleneck,
and if I switch
From: David kerber [mailto:dcker...@verizon.net]
Subject: Re: Performance with many small requests
From these tests, it looks like, under windows XP and java 1.5
any way, that atomics are always faster
Try it under 1.6; Sun made major improvements to synchronization handling
between 1.5
Caldarale, Charles R wrote:
From: David kerber [mailto:dcker...@verizon.net]
Subject: Re: Performance with many small requests
From these tests, it looks like, under windows XP and java 1.5
any way, that atomics are always faster
Try it under 1.6; Sun made major improvements
From: David kerber [mailto:dcker...@verizon.net]
Subject: Re: Performance with many small requests
That's good to know; that would be an incentive for me to migrate this
app to 1.6 and Tomcat 6.
You don't need to move to Tomcat 6 to use a 1.6 JVM; you can use the Tomcat you
already have
From: David kerber [mailto:dcker...@verizon.net]
Subject: Re: Performance with many small requests
How difficult are keepalives to implement?
That would depend on your client. Looks like the Apache http client supports
it, but I haven't used it.
- Chuck
THIS COMMUNICATION MAY CONTAIN
On May 12, 2009, at 13:09, Caldarale, Charles R chuck.caldar...@unisys.com
wrote:
From: David kerber [mailto:dcker...@verizon.net]
Subject: Re: Performance with many small requests
From these tests, it looks like, under windows XP and java 1.5
any way, that atomics are always faster
Try
Christopher Schultz wrote:
On May 12, 2009, at 13:09, Caldarale, Charles R
chuck.caldar...@unisys.com wrote:
From: David kerber [mailto:dcker...@verizon.net]
Subject: Re: Performance with many small requests
From these tests, it looks like, under windows XP and java 1.5
any way, that atomics
From: David kerber [mailto:dcker...@verizon.net]
Subject: Re: Performance with many small requests
When (what java version) did those string operation optimizations
happen? Sun's web page that talks about this (and explicitly says
that string buffers are usually faster than direct string
From: David kerber [dcker...@verizon.net]
My cpu usage for tomcat
has gone from bouncing between 0 and 1 in task manager, to a steady 2
since more threads are now actually doing work instead of waiting around
for their turn at the code, my disk writes per sec in perfmon have also
more than
Peter Crowther wrote:
From: David kerber [dcker...@verizon.net]
My cpu usage for tomcat
has gone from bouncing between 0 and 1 in task manager, to a steady 2
since more threads are now actually doing work instead of waiting around
for their turn at the code, my disk writes per sec in perfmon
From: David kerber [mailto:dcker...@verizon.net]
Subject: Re: Performance with many small requests
From what I can tell now, it looks like most of my wait time is on
socket reads. In the thread dump I took about 20 minutes ago, I didn't
see any waiting on disk writes:
The line listed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter,
On 5/8/2009 7:26 AM, Peter Crowther wrote:
Decrypt: parallel.
Send ack: parallel.
Increment counters: synced.
Write to log file: synced (or you'll have some very odd stuff happening).
I'd go further and suggest that you re-factor your
Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter,
On 5/8/2009 7:26 AM, Peter Crowther wrote:
Decrypt: parallel.
Send ack: parallel.
Increment counters: synced.
Write to log file: synced (or you'll have some very odd stuff happening).
I'd go further and
From: David Kerber [mailto:dcker...@verizon.net]
Subject: Re: Performance with many small requests
Incrementing a counter can't be much of a synchronization bottleneck,
and if I switch to an AtomicInteger, it should be even less of one.
Actually, it won't. There's a slight performance
Xie Xiaodong wrote:
Hello,
IMHO, it would be better to use java concurrency package now than to use
the old synchronize mechanism. The old mechanism is to low level and error
prone. I think you could have a thread pool and some handler pattern to
handle the request from your customer.
From: David Kerber [mailto:dcker...@verizon.net]
The synchronized section doesn't do a whole lot, so it
doesn't take long to process.
Indeed. So take a thread dump and see what's happening before making *any*
changes to this key part.
My question is, what kinds of operations need to be
Mark Thomas wrote:
Xie Xiaodong wrote:
Hello,
IMHO, it would be better to use java concurrency package now than to use
the old synchronize mechanism. The old mechanism is to low level and error
prone. I think you could have a thread pool and some handler pattern to
handle the request from
Peter Crowther wrote:
From: David Kerber [mailto:dcker...@verizon.net]
The synchronized section doesn't do a whole lot, so it
doesn't take long to process.
Indeed. So take a thread dump and see what's happening before making *any*
changes to this key part.
I'm trying; if I use
From: David kerber [mailto:dcker...@verizon.net]
Subject: Re: Performance with many small requests
if I use tomcat5w.exe to take a thread dump, where does it
leave the file?
If you can take a thread dump with tomct5w.exe, please let us know how, because
I'm certainly not aware of it having
Caldarale, Charles R wrote:
From: David kerber [mailto:dcker...@verizon.net]
Subject: Re: Performance with many small requests
if I use tomcat5w.exe to take a thread dump, where does it
leave the file?
If you can take a thread dump with tomct5w.exe, please let us know how, because
I'm
From: David kerber [mailto:dcker...@verizon.net]
Subject: Re: Performance with many small requests
If you right-click on the icon in the system try, one of the items says
Thread dump.
Right - sorry for forgetting that. I never install from the .exe download (too
restrictive), so I never
Caldarale, Charles R wrote:
From: David kerber [mailto:dcker...@verizon.net]
Subject: Re: Performance with many small requests
If you right-click on the icon in the system try, one of the items says
Thread dump.
Right - sorry for forgetting that. I never install from the .exe download
Peter Crowther wrote:
From: David Kerber [mailto:dcker...@verizon.net]
The synchronized section doesn't do a whole lot, so it
doesn't take long to process.
Indeed. So take a thread dump and see what's happening before making *any*
changes to this key part.
My question is, what kinds of
Pid wrote:
Peter Crowther wrote:
From: David Kerber [mailto:dcker...@verizon.net]
The synchronized section doesn't do a whole lot, so it
doesn't take long to process.
Indeed. So take a thread dump and see what's happening before making *any*
changes to this key part.
My
-Original Message-
From: David kerber [mailto:dcker...@verizon.net]
Subject: Re: Performance with many small requests
That said, any idea where that might leave the thread dump?
After some experimentation, I found it in jakarta_service_MMDD.log in
Tomcat's logs directory
From: Pid [mailto:p...@pidster.com]
Subject: Re: Performance with many small requests
Would a single thread executor service alongside an atomic counter be
useful here? (my concurrency knowledge isn't so hot).
Sounds like overkill just for ordering. Synchronization with the single thread
Caldarale, Charles R wrote:
-Original Message-
From: David kerber [mailto:dcker...@verizon.net]
Subject: Re: Performance with many small requests
That said, any idea where that might leave the thread dump?
After some experimentation, I found it in jakarta_service_MMDD.log
From: David kerber [mailto:dcker...@verizon.net]
Also, right now I'm doing a .flush() after the .write() to the log
file. Is that usually necessary, other than to avoid losing
data lines in case of a system failure?
No, other than that.
What disk subsystem are you running on? Start
From: David kerber [mailto:dcker...@verizon.net]
Subject: Re: Performance with many small requests
Apparently it doesn't spit out the thread dump if the logging level is
set to error, because I had looked there, and looked again just now (in
case it took longer than I expected).
Mine
Peter Crowther wrote:
From: David kerber [mailto:dcker...@verizon.net]
Also, right now I'm doing a .flush() after the .write() to the log
file. Is that usually necessary, other than to avoid losing
data lines in case of a system failure?
No, other than that.
What disk subsystem are you
From: David kerber [mailto:dcker...@verizon.net]
I'll look into that to be sure, but I don't think the HD is limiting.
I think I agree with you, but it's a classic area that people miss - Intel have
done entirely too good a job of branding the CPU as the only place where speed
matters!
David kerber wrote:
Caldarale, Charles R wrote:
-Original Message-
From: David kerber [mailto:dcker...@verizon.net]
Subject: Re: Performance with many small requests
That said, any idea where that might leave the thread dump?
After some experimentation, I found
From: David kerber [mailto:dcker...@verizon.net]
Now that I've got a thread dump, what am I looking for?
You found it first time :-). Now the hard part - fixing it.
I've got a
bunch of sections like this, pretty much all of which are waiting to
lock 0x057c73e0. Is there any way to figure
Peter Crowther wrote:
From: David kerber [mailto:dcker...@verizon.net]
Now that I've got a thread dump, what am I looking for?
You found it first time :-). Now the hard part - fixing it.
Yeah, that's what I figured!
I've got a
bunch of sections like this, pretty much all of which
From: David kerber [mailto:dcker...@verizon.net]
I also have quite a few blocks like this:
[...]
[2009-05-08 10:43:23] [info] - locked 0x0510e6e0 (a
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)
[...]
I assume these are just threads waiting for something to do
(waiting for a
From: Peter Crowther [mailto:peter.crowt...@melandra.com]
Subject: RE: Performance with many small requests
They look like spares in the pool, but my knowledge of Tomcat's
internals is limited.
Yes, they are just waiting for requests to show up.
Only one thread can get into the method
Caldarale, Charles R wrote:
From: Peter Crowther [mailto:peter.crowt...@melandra.com]
Subject: RE: Performance with many small requests
They look like spares in the pool, but my knowledge of Tomcat's
internals is limited.
Yes, they are just waiting for requests to show up.
Only one
From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com]
Strictly speaking, that's one thread per *servlet* object; if
using the SingleThreadModel (let's hope not), the container
is allowed to create multiple instances.
Good point in the general case, but I rather suspect David would
From: Peter Crowther [mailto:peter.crowt...@melandra.com]
Subject: RE: Performance with many small requests
Meh, why don't I bow out and leave Chuck to give all the good answers?
A) I don't have them all.
B) What I do have is meetings, bloody meetings and won't be answering promptly
Peter Crowther wrote:
From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com]
Strictly speaking, that's one thread per *servlet* object; if
using the SingleThreadModel (let's hope not), the container
is allowed to create multiple instances.
Good point in the general case, but I
From: David kerber [mailto:dcker...@verizon.net]
The tomcat application simply takes the post request,
does a checksum verification of it, decrypts the
lightly-encrypted data,
and writes it to a log file with the timestamps and site identifiers I
mentioned above. Pretty simple processing,
Andre-John Mas wrote:
On 7-May-2009, at 17:28, Peter Crowther wrote:
From: David kerber [mailto:dcker...@verizon.net]
The tomcat application simply takes the post request,
does a checksum verification of it, decrypts the
lightly-encrypted data,
and writes it to a log file with the timestamps
On 7-May-2009, at 19:05, David Kerber wrote:
Andre-John Mas wrote:
That would be my impression too. It is best to avoid making the
synchronized scope so large, unless there is a very good reason.
David, do you have any reason for this? Beyond the counter, what
other stuff do you
Hello,
IMHO, it would be better to use java concurrency package now than to use
the old synchronize mechanism. The old mechanism is to low level and error
prone. I think you could have a thread pool and some handler pattern to
handle the request from your customer.
2009/5/8 Andre-John Mas
87 matches
Mail list logo
