Java Performance Tuning

Java(TM) - see bottom of page

|home |services |training |newsletter |tuning tips |tool reports |articles |resources |about us |site map |contact us |

Our valued sponsors who help make this site possible
ManageEngine's Site24x7: End-to-End analysis on Java EE web transactions. Sign up for FREE! 

AppDynamics: Get complete browser to backend visibility. Monitor Now! 

New Relic: Try free w/ production profiling and get a free shirt! 

News March 2008

Why is my application so slow?
Learn 3 ways to detect Java Application Performance Trends

JProfiler
Get rid of your performance problems and memory leaks!

Chart Java Jitter with jHiccup
Monitor and identify pauses in your Java apps. Download now


Java Performance Training Courses
COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs

See Your Message Here
You could have your tool advertised here, to be seen by thousands of potential customers

Java Performance Tuning, 2nd ed
The classic and most comprehensive book on tuning Java

Java Performance Tuning Newsletter
Your source of Java performance news. Subscribe now!
Enter email:


ManageEngine
ManageEngine's Site24x7: End-to-End analysis on Java EE web transactions. Sign up for FREE!

AppDynamics
AppDynamics: Get complete browser to backend visibility. Monitor Now!

New Relic
New Relic: Try free w/ production profiling and get a free shirt!


Why is my application so slow?
Learn 3 ways to detect Java Application Performance Trends

JProfiler
Get rid of your performance problems and memory leaks!

Chart Java Jitter with jHiccup
Monitor and identify pauses in your Java apps. Download now


Back to newsletter 088 contents

I was using a C# client (not a client I wrote, it connected to a Java server). Its performance sucked. Of course, as I'm not one of those slashdot ranters, I know better than to say it was C#'s fault. It was, of course, that the particular configuration that I was running had not been performance tuned (or even performance tested) - the same is true for anything written in any language. You can get sucky performance from anything - and even well written code can produce bad performance, so I don't even assume that the code was badly written. Any non-trivial app really needs performance testing, and quite probably performance tuning too.

Then the C# client deadlocked. At least I think it deadlocked - it stopped updating the app screen, which went white-ish, and showed the hourglass cursor. It was taking no CPU (from previously maxxing the CPU), and would not refresh at all. It had 40 threads running - or, more precisely, sitting completely idle. My experience is that this very likely indicates a deadlock.

A note from this newsletter's sponsor

Wily Technology delivers what you need: Availability, Performance and Control
The most critical web applications in the world are managed by
software from Wily, the leader in enterprise application management

So, naturally, I asked the dev team behind the client (it was a production client, developed in-house by one of my customers), how to dump the threads so that I could send them the listing of the deadlock. Apparently you can't. Well, you can, but you have to attach something - a debugger I think. Something that I didn't have. You can attach remotely, but that was problematic given where I was and where they were. There isn't any simple mechanism to just get the dump. Coming from the Java world, where we've had cntrl-brk (on windows, and on unix cntrl-\ or kill -3) from practically the very start, this felt like stone age technology. Is C# really that backward, or was it just lack of experience on the part of the dev team? I don't know, I don't do any C# development. I was left distinctly unimpressed with C#. But I'm all for competition. So if Microsoft engineering is reading, I have a suggestion - go and read the Java troubleshooting guide, and make sure a production C# app can do the same types of monitoring or better. It's the difference between a runtime system that is prime time, and one that is not quite ready.

Now on with the newsletter. We have our usual lists of Java performance tools, news, articles, and we also have Kirk interviewing Dan Diephouse on XML performance; Javva The Hutt tells us about the effects of the credit crunch; and, as usual, we have extracted tips from all of this month's articles.

A note from this newsletter's sponsor

dynaTrace software: >> Monitor. Diagnose. Resolve. >>
Get this JavaMazine article about java performance tools and learn
that dynaTrace is the only solution covering profiling, diagnosis and monitoring

News

Java performance tuning related news.

Tools

Java performance tuning related tools.

A note from this newsletter's sponsor

Better code means better software, and JProbe(R) can help. JProbe finds
and fixes code problems in pre-production, and now with a new lower
price it's easier than ever to develop great code. See how.

Articles

Jack Shirazi


Back to newsletter 088 contents


Last Updated: 2014-08-05
Copyright © 2000-2014 Fasterj.com. All Rights Reserved.
All trademarks and registered trademarks appearing on JavaPerformanceTuning.com are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. JavaPerformanceTuning.com is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
URL: http://www.JavaPerformanceTuning.com/news/news088.shtml
RSS Feed: http://www.JavaPerformanceTuning.com/newsletters.rss
Trouble with this page? Please contact us