-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 13-May-2009, at 09:16, David kerber wrote:
Christopher Schultz wrote:
...
Since a String object is immutable, one should always use a
StringBuffer (preferably a StringBuilder, these days) when you are
constructing strings in a piecemeal fashion, then convert to String
when complete.
Thi
Christopher Schultz wrote:
...
Since a String object is immutable, one should always use a
StringBuffer (preferably a StringBuilder, these days) when you are
constructing strings in a piecemeal fashion, then convert to String
when complete.
This advice is good when constructing a long str
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chuck,
On 5/12/2009 5:03 PM, Caldarale, Charles R wrote:
>> From: David kerber [mailto:dcker...@verizon.net] Subject: Re:
>> Performance with many small requests
>>
>> When (what java version) did those string operation
Caldarale, Charles R wrote:
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 us
> 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 usu
Christopher Schultz wrote:
On May 12, 2009, at 13:09, "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 fa
On May 12, 2009, at 13:09, "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
> 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
> 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 us
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 to
> 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 ha
-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 synchroniz
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 a
> 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 testin
> 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
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
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 TIME_
> 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]
> 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
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]
> 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. Apo
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 that
Leon Rosenberg wrote:
On Tue, May 12, 2009 at 6: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 to an AtomicIn
> 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
On Tue, May 12, 2009 at 6: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 switc
> 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. The
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 s
-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
> 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 dis
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 have
> 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 t
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 rath
> 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&#
> 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
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.
Onl
> 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: 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
> (waitin
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 ar
> 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 f
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 it in
> 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!
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 r
> 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
> 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 Perf
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 in
> 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. Synchroniza
> -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&#
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 quest
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, wh
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 .ex
> 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
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&#
> 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 certa
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 tomcat5
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
> 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
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
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
>
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 synchro
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 a
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 and site
identifiers 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 processi
I'm having performance issues with my installation of TC 5.5.15, Java
1.5.0_12, on Windows 2003 server 32 bit, dual-cpu dual-core (4 cores
total), 4GB physical RAM.
Tomcat startup params:
JvmMs = 256
JvmMx = 512
JvmSs = 0
This was the original entry in my server.xml, which has been running for
t
64 matches
Mail list logo
