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 |
Tools: | GC log analysers| Multi-tenancy tools| Books| SizeOf| Thread analysers|

Our valued sponsors who help make this site possible
JProfiler: Get rid of your performance problems and memory leaks! 

Training online: Threading Essentials course 

Newsletter no. 27, February 28th, 2003

JProfiler
Get rid of your performance problems and memory leaks!


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

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:


Training online
Threading Essentials course


JProfiler
Get rid of your performance problems and memory leaks!


Mea Culpa. Javaworld didn't stop access to its archived articles. More precisely, access was withheld for one week, then restored after someone decided the policy wasn't going to make them a fortune. Well done JavaWorld, and silly old me for writing last month's editorial just when the restriction was in effect.

Swing vs SWT was the hot news this month. Amidst some propaganda for each side, it seems that each has its place. More to the point, it seems like we have Sun backing Swing and IBM backing SWT and the two sides intend to fight it out with each other in trying to make their GUI framework easier to use and faster to respond. Whoopee! Don't ya' just love competition.

We also had the outing of a two year old Sun memo that indicated Sun didn't have Java performance on Solaris as a top priority. Is that really so surprising? Two years ago, Java had only just become the de-facto server-side language, and Sun has never really been that responsive to ongoing Java trends. They've tended to be looking forward to the next best thing, or responding to some torrent or other, rather than concentrating on what today's community wants. That's the kind of attitude that gave us Java in the first place. It's good for the Java community, because it leaves plenty of opportunities for everyone else to service those ongoing trends.

A note from this newsletter's sponsor

Java Performance Tuning, 2nd ed. covers Java SDK 1.4 and
includes four new J2EE tuning chapters. The best value Java
performance book just got even better! Order now from Amazon

I'd like to say that I'm keeping up with all the articles that come out each month. But I can't. The truth is that my backlog continues to grow each month. But on the positive side, that's actually because there are so many articles every month with something to say about Java performance. The articles I have got to this month include a swathe (four!) articles on GC in the IBM JVM, another bunch on performance/capacity management, a couple on J2ME, and others on Swing, XML, JMS and more.

Javva The Hutt talks about infinitely fast computers, and comes to a surprising conclusion; we interview Alex Rossi who successfully scaled a large enterprise Java system seven years ago; our question of the month explains how to choose a profiler; the roundup covers several very interesting questions and answers from performance discussion groups, and, of course, we have all the latest performance tips extracted in concise form.

A note from this newsletter's sponsor

Measure, analyze and maximize J2EE application performance
during load testing with PerformaSure. Read the Aberdeen
white paper "Honing In on J2EE Performance Assurance".

News

Java performance tuning related news.

A note from this newsletter's sponsor

Get a free download of GemStone Facets 2.0 and see how this
patented technology supports JCA 1.0 to seamlessly integrate
with J2EE application servers to enhance performance.

Tools

Recent Articles

Older Articles

Jack Shirazi


The Roundup

A question was asked about merging two datasets, one a sorted list, the other unsorted, the result to be sorted. Various solutions were presented: use the Collections.sort(); Insertion sort; Quicksort; Insertion sort plus binary search; sort the unsorted set then merge with mergesort; a custom sorting technique. None of the respondents suggested doing it the easiest way then timing it to see if performance was acceptable BEFORE trying to figure out the quickest way. RTFM. Doh.

Another poster seemed to be asking whether he should use sleep() to reduce the load from his back-end process. A curious question, we were given no idea of what the process was except that it used Tomcat. He later found that his process used 100% CPU, so he inserted sleep(1000) and all was well. Sometimes these discussion threads seem to consist of aliens doing things too esoteric to understand. This guy was either a genius or an idiot. I don't have an opinion which, I admit that I'm ignorant enough to be wrong either way.

JavaGaming.org

The limitations of MappedBuffer, the buffer obtained from mapping files into memory using NIO, came up. The file was very large, and the system (XP in this case) seemed to be taking all the free memory for the file cache to handle the mapping. Other processes were basically swapped out, so switching tasks to another activity was very slow, probably because the system had to page that process back into memory. The poster redeveloped the task without NIO, using RandomAccessFile, and found that the speed was faster, and the problem of swamped memory went away, i.e. other tasks were now responsive. The question was, shouldn't NIO memory mapped files provide better performance? The only response suggested that MappedBuffer's were not necessarily good for random writes. The responder, Toby Reyelts, went on to say "if your mapped file is larger than your actual working memory, and you're performing lots of random write access ... the paging system will constantly be evicting entire pages to disk (even when only a few bits have changed) so it can reload pages that were previously evicted, just to swap them back out to disk again."

For a couple of years, Sun has maintained that object pooling is unnecessary and even detrimental to performance. So a thread looking at object creation and GC, compared to pooling and reusing objects in 1.4.1 looked interesting. The results of the discussion looked to be that reusing objects from a static pool still had a significant edge over creation & GC of objects, at least for some kinds of applications (such as the ray-tracing one tested). In addition, ThreadLocal is much faster in 1.4.1, and Thread.currentThread() is now so fast it's nearly free.

The Server Side

A question asking about EJB Local performance produced only one reply: that Locals are fast because they avoid marshalling overheads.

Another asking about J2EE compliant caching tools produced two vendor replies: eXcelon's Javlin and Tangosol Coherence.


Javva The Hutt

As usual, I'm months behind on my reading. So I've only just read Paul Davies article on How to Build a Time Machine. (I met Prof Davies once, and he's every bit as enthusiatic in person as he comes across in his articles).

The article is hardly news (as in new info), but it's always nice to get the old grey matter thinking. What leapt out at me this time is that micro-wormholes could enable time travel at the particle level. So you could conceivably build computer gates which produced results in essentially no time. Technically, you could produce results before you started the calculation, but assuming Hawking's chronology protection conjecture is correct, that would be ruled out. But the conjecture would not rule out calculations that took no time. So you could build an infintely fast computer. NP-complex? Who cares! Elegant algorithms? Who cares! The most stupidly inefficient computer program would still take ... no time.

I figure 50 years is enough to get some kind of time-acceleration technology running. Let's see, current projections are that Moore's law starts to run out around 2020. I reckon there'll be some breakthroughs in 3-D chip architectures that'll extend that another 15 years. Throw in some unknown (to me) technology that extends Moore's law another 15 years beyond that, then we'll enter the realm of time-speeded chips.

If we take the conservative Moore's law we get a 30-fold CPU speedup every 10 years. From experience, I know that dumb-couldn't-care-less-about-performance programming runs about 1,000 times slower than a reasonably tuned app. Given that a reasonably tuned app runs okay on a modern CPU, in another 20 years you can write your Java app any way you want. Well not quite, the CPU won't be a problem, and memory probably also won't be a concern but I/O will still be limiting and other shared resources will be a problem. So the bottlenecks will be somewhere else, and I guess you'll still need to tune your app. That's pretty funny. An infinitely fast computer will still need to have it's software tuned to run it adequately fast enough!

Diary of a Hutt

January 15. Ah, the rigours of the new year. Why does it take a week to get into gear every time any public holidays roll around? I bet if most businesses could measure productivity on a monthly basis, they'd see big dips in December and January. And maybe Feb (too cold, or too hot if you're in the other hemisphere from me). And March, all those hormones surging. And April, because ... Okay, maybe there always some reason or other why people are distracted. I'm allowed to ramble. It's my diary.

January 22. TEAM FRELLING LEADER. That's it. Dribble pay rise, no real title, but more management work. ******* ******** *** ** ** **** [expletive sentence deleted]. Now I know what that little snide Weevil was up to. He was getting my promotion downgraded to a ******* ***** ** ****.

January 29. Apparently I was in a very dark mood last week. I do aplogize to any readers of a more sensitive nature. I was slightly disappointed at the final status discussions over my performance group. Instead of what I'd expected, i.e. a new mini-department, I've become team leader for a new mini-team. I'm feeling cheerier this week. On a side note, it appears that Weevil sent a very insulting and partially pornographic email to several directors this week, which has caused rather a lot of uproar.

January 30. The security and administration team seemed to have tracked down Weevil's alleged email as a forgery sent via an open email server which someone installed on one of the spare machines. It seems that there is no way of tracking down the culprit, because no logs were made on that machine. The security team have altered system-wide configurations to ensure that this type of activity can never occur again. Given the lack of available evidence, the case has been closed and Weevil absolved of blame. What a naughty person we must have somewhere in our organization.

BCNU

Javva The Hutt.


The Interview: Alex Rossi

This month I had the pleasure of interviewing Alex Rossi, a technology partner at Accenture. I first met Alex about seven years ago when he was project manager on one of the largest Java projects in the world - and that was 1996 when Java was only in the low 1.1's. No JIT, no HotSpot, basic garbage collection, and very few optimizations in the core classes! If he could make an enterprise project scale then (and he did), it's worth finding out what he's learned.

Q. Can you tell us a bit about yourself and what you do?

I am a technology partner in Accenture, my role is to identify business opportunities involving IT integration and n-tier architectures. We help our clients implement these at all levels, at the organisational level, the process level, the tool level, and from the design/build/run standpoint. My focus is primarily on open architectures, with Java being the core business solution on the application server and integration layers.

Q. You were an early Java adopter and by 1996 you were already involved in one of the biggest Java projects in the world at the time. Was that a sucessful project?

Definitely yes, we succeeded in a very complex integration thanks to our global approach, which considered the importance of creating a sound development architecture and the related processes needed to create a professional environment capable of supporting more than 100 developers. This was when Java IDE and design tools were at their infancy. We also had to pay a lot of attention to the operational side of the development solution, because at that time the Java marketplace did not supply the vast array of tools and products you can find now.

Q. What performance lessons did you learn from that project?

"Trop d'objet tue l'objet" - A too much object-oriented system kills object orientation, meaning that being too purist in OO leads to a system which has to handle millions of objects, which had serious performance issues and also maintenance complexity issues.

I would say that you need to plan for a "denormalization" process like the one you do in the E/R world. To achieve good performance you need to balance simplicity against the flexibility and "beauty" of your OO model.

Q. What do you consider to be the biggest Java performance issue currently?

Tuning the number of server JVMs serving the clients and tuning the number of threads per JVM is still a guru task, not to mention the complexity of this tuning when it has to be done in a specific container environment. Also Garbage Collecting, although it has significantly improved in the latest JVM versions, can represent an issue especially in real time systems when you need to handle the possibility of having a system "freezing" or significantly slowing down for a couple of seconds during GC.

Q. Do you know of any requirements that potentially affect performance significantly enough that you find yourself altering designs to handle them?

Integrating your application server execution with your mainframe system achieves full reusability, but you walk on thin ice to get a decent end-user performance. You have to balance the number of layers and systems you have to cross in order to get data, against the performance cost of leaving data on the mainframe. To obtain acceptable performance I have often had to replicate business code or data onto the application server.

Q. What are the most common performance related mistakes that you have seen projects make when developing Java applications?

Not planning a serious performance and scalability test window. For a complex project, I am talking about 2-4 months with a 3-5 person dedicated performance team.

Q. Which change have you seen applied in a project that gained the largest performance improvement?

Handling the effects of the last question, i.e. creating a team which is focused on operational and performance issues.

Q. Have you found any Java performance benchmarks useful?

We have used many, but I really believe in the specificity of performance issues for each project and on the need for running adequate performance tests. Also, many benchmarks are commercially baised towards specific platforms/products which makes them less useful.

Q. Do you know of any performance related tools that you would like to share with our readers?

I have found OptimizeIT and Mercury LoadRunner two excellent tools, one in the domain of single user tuning of the application, the other in tuning of the application for scalability.

Q. Do you have any particular performance tips you would like to tell our readers about?

Forget about "Java takes care of object allocation and release". If you want to understand and tune your application, you need to understand the object allocation mechanisms of the JVMs. Do not hesitate in investing to create the right skills and buying the right tools for managing this very specific and important task.

(End of interview).


Question of the Month

Which profiler should I use?

The most expensive you can buy. If everyone in the I.T. industry were to spend a little more money on I.T. products, the I.T. industry would be booming just like in early 2000 and I could retire sooner. Apart from that, the more expensive the profiler, the more features it is likely to have.

On the other hand, the more accurate answer is probably that you should use the profiler that is within your budget and that will be the most productive for your project. Here is a procedure for you to decide on which profile to choose:

  1. Decide on your budget for a profiler (it can be $0.00, this procedure still works).
  2. Go to http://www.JavaPerformanceTuning.com/resources.shtml and use that page to get your list of all available profilers. Bear in mind that most commercial IDEs also come with a profiler, so if you are choosing an IDE, factor that in, and if you already have an IDE add your IDE's profiler to the list.
  3. Check also the various Java magazines for their "choices of the year" profiler. Several have reader's choices each year (JDJ and JavaPro at least), and also editor's choice too. These lists can be useful to make sure you haven't missed any profilers, and also may give you an idea of which profilers are possibly better. However do note that reader's choices are elected by online voting and these choices can be manipulated if enough effort is made, so don't rely on these results to select a profiler.
  4. Cross off all profilers that are outside your budget. (If your budget is $0.00, you will be left only with the free profilers and any you already have access to, such as your IDE profiler).
  5. Select a runnable application, component or partially completed project code that you can run which is likely to have performance problems, to use as a test application.
  6. Evaluate each profiler, using each profiler on your test application to determine and fix the bottlenecks. All commercial profilers should have a trial period available for evaluation. Note the first two profilers you used, and repeat their evaluation a the end of the series. The first two profilers will seem more difficult to use initially, because you are getting used to using profilers, getting used to the bottlenecks in the test application, and working out the fixes to apply. By repeating their evaluation, you counteract this bias.
  7. You now have more experience at understanding the benefits, drawbacks, ease of use and productivity of various profiler features than most of the profiler creators. At this point you have probably already chosen your profiler. If not, then none of them stood out for you. In which case eliminate those that you definitely did not want, and select the cheapest one remaining.
  8. Repeat this procedure when you need to upgrade your profiler. Bear in mind that competitors may be willing to give you their upgrade price if you trade your old profiler in for their one.
  9. Congratulations. You are now the proud owner of a Java profiler. Use it carefully and keep it in good working order, and it will last you many years. Keep going to http://www.JavaPerformanceTuning.com/ to find the latest performance tips, and you and your profiler will have a long and successful lifetime.

The JavaPerformanceTuning.com team


Tips

http://dev2dev.bea.com/articlesnews/discussion/thread.jsp?thread=zadrozny_002
BEA JMS performance (Page last updated January 2003, Added 2003-02-28, Author Peter Zadrozny, Publisher BEA). Tips:

http://developer.java.sun.com/developer/community/chat/JavaLive/2003/jl0121.html
Swing perf community chat (Page last updated January 2003, Added 2003-02-28, Author Edward Ort, Publisher Sun). Tips:

http://developer.java.sun.com/developer/EJTechTips/2003/tt0114.html#2
Preventing Repeated Operations (Page last updated January 2003, Added 2003-02-28, Author Mark Johnson, Publisher Sun). Tips:

http://www-106.ibm.com/developerworks/ibm/library/i-garbage1/
IBM GC 1 (Page last updated August 2002, Added 2003-02-28, Author Sam Borman, Publisher IBM). Tips:

http://www-106.ibm.com/developerworks/ibm/library/i-garbage2/
IBM GC 2 (Page last updated August 2002, Added 2003-02-28, Author Sam Borman, Publisher IBM). Tips:

http://www-106.ibm.com/developerworks/library/i-garbage3.html
IBM GC 3 (Page last updated September 2002, Added 2003-02-28, Author Sam Borman, Publisher IBM). Tips:

http://www-106.ibm.com/developerworks/ibm/library/i-gctroub/
GC (Page last updated January 2003, Added 2003-02-28, Author Sumit Chawla, Publisher IBM). Tips:

http://www-106.ibm.com/developerworks/java/library/j-jtp0114/
floating point and decimal numbers (Page last updated January 2003, Added 2003-02-28, Author Brian Goetz, Publisher IBM). Tips:

http://www-106.ibm.com/developerworks/java/library/wi-devo/
Performance of networked J2ME apps (Page last updated January 2003, Added 2003-02-28, Author Michael Abernethy, Publisher IBM). Tips:

http://www-106.ibm.com/developerworks/library/x-databdopt2/
XML data binding performance (Page last updated January 2003, Added 2003-02-28, Author Dennis M. Sosnoski, Publisher IBM). Tips:

http://www.adtmag.com/article.asp?id=7164
Manage Java apps for premium performance (Page last updated January 2003, Added 2003-02-28, Author Peter Bochner, Publisher ADTMagazine). Tips:

http://www.devx.com/Intel/Article/10640
Four Critical Issues for Mobile Apps Developers (Page last updated January 2003, Added 2003-02-28, Author Alan Zeichick, Publisher DevX). Tips:

http://www.e-promag.com/eparchive/index.cfm?fuseaction=viewarticle&ContentID=2836&websiteid=
Concise Guide to WebSphere Capacity Management (Page last updated January 2003, Added 2003-02-28, Author Ruth Willenborg Stacy Joines, Publisher e-ProMag.com). Tips:

http://www.devx.com/enterprise/Article/10549
Web service management (Page last updated January 2003, Added 2003-02-28, Author Justin Murray, Publisher DevX). Tips:

http://www.devx.com/enterprise/Article/10397
Applying Design Issues and Patterns in Web Services (Page last updated January 2003, Added 2003-02-28, Author Chris Peltz, Publisher DevX). Tips:

http://www.e-promag.com/eparchive/index.cfm?fuseaction=viewarticle&ContentID=1492&websiteid=
Monitoring Performance with WebSphere (Page last updated January 2002, Added 2003-02-28, Author Ruth Willenborg, Publisher e-ProMag.com). Tips:

Jack Shirazi


Last Updated: 2017-12-29
Copyright © 2000-2017 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/newsletter027.shtml
RSS Feed: http://www.JavaPerformanceTuning.com/newsletters.rss
Trouble with this page? Please contact us