tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Gainty" <>
Subject Re: Code performance question #2
Date Tue, 08 Aug 2006 12:18:54 GMT
Good Morning --
Please read
paying particular attention to race conditions, deadly embraces and basic coverage of Functions

For the first iteration I would strongly urge you to use JCoverage

If you have the money then look into Clover!default.jspa;jsessionid=F235AE9B72517AA7B94BC19A1D8D3559

If your clients require lightning fast performance follow the lead of google and other search
engines and code the most CPU intensive
routines in C++

Caveat Emptor,
Martin --
This email message and any files transmitted with it contain confidential
information intended only for the person(s) to whom this email message is
addressed.  If you have received this email message in error, please notify
the sender immediately by telephone or email and destroy the original
message without making a copy.  Thank you.

----- Original Message ----- 
From: "Peter Crowther" <>
To: "Tomcat Users List" <>
Sent: Tuesday, August 08, 2006 5:02 AM
Subject: RE: Code performance question #2

> From: David Kerber [] 
> Do you think 
> it be more efficient to scan the string once and grab the 
> field values as I get to each field marker?


> Yes, the machine is cpu-bound.  
> My 768k data line will spike the cpu to 100% and hold it 
> above 95% until 
> the transmission queues on the other end of the WAN are 
> caught up.

(Wince).  Ouch.

> watching task manager tells me that the disk subsystem 
> seems to be able to keep up.

If you're on Windows, start up Performance Monitor and add the following

Processor: % CPU time
Memory: Pages/sec
Physical disk: Avg disk queue length (by array or disk if you have more
than one)

(I would add network: Bytes/sec, but it seems that's not the bottleneck)

The key disk counter is the queue length.  MS documentation suggests
that when the average queue length climbs above 2 per spindle in the
array, your disk subsystem is likely to be the bottleneck.  So if you
have a 5-disk array, queues that climb over 10 show a disk issue.

Memory: Pages/sec is a general indicator of paging traffic.
COnsistently high values tend to show a paging problem that could
possibly be solved by adding RAM.

Processor: % CPU time is a general processor counter.  Sustained values
above 80% tend to indicate a bottleneck according to MS.  It's sometimes
worth adding the % user time counter as well to see whether the issue is
your code or OS code.

> I haven't run a profiler on this code; I've tried, but getting the 
> configuration figured out has stumped me every time.  I 
> picked out these 
> particular routines (and one other I haven't posted) because of the 
> principal that 90% of the cpu time is taken by 10% of the code, and 
> these routines are the only loops in the entire servlet (i.e. 
> the only 
> lines of code which are executed more than once per incoming data 
> line).

Seems like a reasonable heuristic, I agree.  You may find that Tomcat
itself is the bottleneck - this is an area where profiling is of great
help.  However, I'd beware hidden complexity: the complexity behind
function calls into third-party libraries.  For example, you say you're
decrypting the arguments.  Depending on the exact crypto algorithm used,
this ranges from moderately expensive to horribly expensive; once again,
profiling would reveal this, and might indicate where a change to the
crypto could be of benefit.

Can you set up a simple Java test harness outside your servlet that
simply calls the servlet's service routine repeatedly with a few sample
lines?  If you can construct something that will run outside Tomcat,
it'll be easier to instrument and you'll be able to analyse the impact
of your tuning changes more easily.  I also see Mark's willing to help
getting a profiler set up... :-).

Sorry to point you off in a different direction from your likely
preferred route, but I've seen a lot of people spend a lot of time
optimising the wrong area of their code.  In a past life, I wrote
highly-optimised classifier code for an inference engine (admittedly in
C++); I found a profiler was the only way to work out what was
*actually* happening.  I ended up getting a factor of 20 out of my code
by combining optimisations in the most unlikely places, giving the
company the fastest engine in the world at that time.  I simply couldn't
have done that with static analysis - I kept guessing wrong!

- Peter

To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message