Good Morning -- Please read http://www.javaranch.com/newsletter/200401/IntroToCodeCoverage.html 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 http://cms.jcoverage.com/ If you have the money then look into Clover http://www.cenqua.com/login!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" <[EMAIL PROTECTED]> To: "Tomcat Users List" <users@tomcat.apache.org> Sent: Tuesday, August 08, 2006 5:02 AM Subject: RE: Code performance question #2 > From: David Kerber [mailto:[EMAIL PROTECTED] > 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. > 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 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 > 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: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
