Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Code performance question #2
Date: Tue, 8 Aug 2006 10:02:10 +0100
Message-ID: <DDBBD1E00935D144AB9563D57EF98D622F7E28@raccoon.melandra.net>
Thread-Topic: Code performance question #2
thread-index: Aca6Ry0D9wfmxIL/RmGyi/EKSj3QCAAf+R4g
From: "Peter Crowther" <Peter.Crowther@melandra.com>
To: "Tomcat Users List" <users@tomcat.apache.org>

> From: David Kerber [mailto:dckerber@verizon.net]=20
> Do you think=20
> it be more efficient to scan the string once and grab the=20
> field values as I get to each field marker?

Yes.

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

(Wince).  Ouch.

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

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

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=20
> configuration figured out has stumped me every time.  I=20
> picked out these=20
> particular routines (and one other I haven't posted) because of the=20
> principal that 90% of the cpu time is taken by 10% of the code, and=20
> these routines are the only loops in the entire servlet (i.e.=20
> the only=20
> lines of code which are executed more than once per incoming data=20
> 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: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org