Recovering after vacation
It has become extremely difficult to put anything in here after nice long vacation. Kind of hints at the significance of, doesn't it?
So what's techie now? Netbeans profiler, my first successful encounter with it today. Works as advertised, but... as any other profiler on this planet, it also LIES. No silver bullet, huh? Basically, launched it with no problems (been using Netbeans 6 with corresponding profiler), fired up standalone JMeter (have yet to try the one integrated with Netbeans and Profiler, but no time for this). Observed typical for my application picture: serialization is highest on the list, but next, surprise! an innocently looking class' hashCode() appears hot (takes 9% of CPU time). Checking the code... hmm... this calss should have been immutable, really. But even if it isn't, no big deal, I put hashCode caching in. So, now I should expect a not exactly 9%, but noticeable reduction in CPU utilization, right? Hell no. Not at all. It's a typical (ph)fantom chase...
What else? Found and filed this strange bug with JMeter (although, frankly, I suspect it could be a bug in Java 6), when JMeter's performance quickly degrades. Nothing like that when JMeter is run with Java 5. It could have to do with JVM command-line parameters that were optimal for Java 5 and JDK 1.4, but Java 6, while honoring these settings (garbage-collection-related ones, specifically), finds itself at a disadvantage. Maybe I'll have time to try getting rid of those parameters set in the JMeter's batch file... Or I could try using newer version of JMeter that allows choice of HTTP clients.
So what's techie now? Netbeans profiler, my first successful encounter with it today. Works as advertised, but... as any other profiler on this planet, it also LIES. No silver bullet, huh? Basically, launched it with no problems (been using Netbeans 6 with corresponding profiler), fired up standalone JMeter (have yet to try the one integrated with Netbeans and Profiler, but no time for this). Observed typical for my application picture: serialization is highest on the list, but next, surprise! an innocently looking class' hashCode() appears hot (takes 9% of CPU time). Checking the code... hmm... this calss should have been immutable, really. But even if it isn't, no big deal, I put hashCode caching in. So, now I should expect a not exactly 9%, but noticeable reduction in CPU utilization, right? Hell no. Not at all. It's a typical (ph)fantom chase...
What else? Found and filed this strange bug with JMeter (although, frankly, I suspect it could be a bug in Java 6), when JMeter's performance quickly degrades. Nothing like that when JMeter is run with Java 5. It could have to do with JVM command-line parameters that were optimal for Java 5 and JDK 1.4, but Java 6, while honoring these settings (garbage-collection-related ones, specifically), finds itself at a disadvantage. Maybe I'll have time to try getting rid of those parameters set in the JMeter's batch file... Or I could try using newer version of JMeter that allows choice of HTTP clients.
posted by denka at 9:27 PM
0 Comments:
Post a Comment
<< Home