The Artima Developer Community
Sponsored Link

Java Community News
Vincent Partington's Enterprise Application Performance Problems Top 10

11 replies on 1 page. Most recent reply: May 4, 2007 7:56 PM by Jeff Ratcliff

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 11 replies on 1 page
Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Vincent Partington's Enterprise Application Performance Problems Top 10 Posted: May 1, 2007 1:40 PM
Reply to this message Reply
Summary
Vincent Partington has been writing about the most pervasive roots of Java EE performance problems. He brings his blog series to a conclusion with a few more nuggets of parting wisdom.
Advertisement

Vincent Partington has written a series of short articles, each article focusing on one potential Java EE application performance problem. In a concluding article, EJAPP Top 10 countdown wrap-up, he shares a few bits of parting advice. Noting that most performance problems arise because of incorrect use of technologies, mostly due to developers not fully understanding how to use a technology, Partington writes that,

Java developers should consider performance an important quality requirement of their application to which they should pay attention from the start to the end of the project... Java developers need to work with the people that can help them improve the performance of their application like application server and database administrators...

Partington covers the following performance-related topics in his series:

10. Excessive logging
Two things happen when you log. First a number of String manipulations are performed ... and then the resulting String is written to a file...

9. Incorrect application server configuration
The J2EE specification can lull the developer into a false sense of security, thinking “As long as I make sure my code is J2EE compliant, it will just run“... Developers should not just throw their EAR file over the wall; developers and application server administrators need to work together on this...

8. Incorrect usage of Java EE
This problem is particularly prevalent in older applications that were developed before the POJO/lightweight revolution a few years back... Lightweight frameworks like Spring allow the developer to pick and choose the infrastructure services (transactions, security, distributed objects) that are needed. Java EE... offers all of them all of the time.

7. Unnecessary use of XML
XML has a number of interesting properties that cause it to be used for a whole range of functions in the average Enterprise Java application... Unfortunately XML processing is heavy on CPU cycles and on memory usage.

6. Improper caching
Done right it can improve the performance of your Enterprise Java application tremendously and can even be essential to reach acceptable performance levels, but sometimes caching itself can be the cause for your performance problems.

5. Excessive memory usage
Excessive memory usage manifests itself in two ways: a large number of allocations (for short-lived objects), or a large number of objects per se.

4. Badly performing libraries
Some development teams will happily pile JAR after JAR into their WEB-INF/lib directory or into their POM file without checking whether that library is really needed (and does not overlap with functionality already offered by other libraries used), without checking whether that library can offer good performance or whether a better performing alternative is available, without reading the documentation to see how it should properly be used, and without defining how the library is going to be used within the application.

3. Incorrectly implemented concurrency
A major cause is lock contention, which only becomes an issue when multiple threads are involved... Applications that perform pretty well under light load may crawl to a halt under heavier load...

2. Unnecessary remoting
In some cases an architecture is designed with remoting built-in for some anticipated future need that never occurs... While remoting is often used in Enterprise Java applications due to the fact that other systems and applications need to be invoked, unnecessary remoting is an important cause of badly performing Enterprise Java applications...

1. Incorrect database usage
In a lot of Enterprise Java projects, the database is treated as a simple bit bucket and the DBA as just the guy that executes the SQL statements on the production machines. This disdain for the database and its experts leads to badly performing applications...

What's the source of your #1 enterprise Java performance problem?


Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Vincent Partington's Enterprise Application Performance Problems Top 10 Posted: May 2, 2007 2:29 AM
Reply to this message Reply
The common thread amongst all the points raised above is that none of the technologies are, of themselves, the problem. In all the cases given it is the incorrect use of the technology that is the issue. In all these examples, the weakest link is the programmer.

What lesson could you learn from that? I'd say the most effective way to improve the quality of your product is to improve the quality of your developers.

Frank Wilhoit

Posts: 21
Nickname: wilhoit
Registered: Oct, 2003

Re: Vincent Partington's Enterprise Application Performance Problems Top 10 Posted: May 2, 2007 5:59 AM
Reply to this message Reply
> In all these examples, the weakest link is the programmer.

Cheap shot. The weakest link is the documentation.

If something can be used rightly or wrongly and it is not obvious which is which, then there is an obligation to provide documentation that explains good and bad practices comprehensively and with brutal clarity.

What we get instead is javadoc: reference documentation without context; necessary but not sufficient.

Ivan Lazarte

Posts: 91
Nickname: ilazarte
Registered: Mar, 2006

Re: Vincent Partington's Enterprise Application Performance Problems Top 10 Posted: May 2, 2007 8:18 AM
Reply to this message Reply
Agreed on the developer comment.

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: Vincent Partington's Enterprise Application Performance Problems Top 10 Posted: May 2, 2007 11:13 AM
Reply to this message Reply
> the weakest link is the
> e programmer.
>

Since Java EE technology was designed, implemented and documented by progammers I'd agree that one way or the other, a programmer is at fault.

robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: Vincent Partington's Enterprise Application Performance Problems Top 10 Posted: May 2, 2007 2:39 PM
Reply to this message Reply
It's comforting to see that even a java zealot can understand that it's the data. Too bad no one has discussed why this might be so. Could it be that Artima devotees DO the bit-bucket waltz? ya think?

Wilfred Springer

Posts: 176
Nickname: springerw
Registered: Sep, 2006

Re: Vincent Partington's Enterprise Application Performance Problems Top 10 Posted: May 3, 2007 12:35 AM
Reply to this message Reply
Hmmmm, if you leave out the specific areas that the author touches (since they are not problematic itself), it seems it all boils down to this: "prevent anything excessive, incorrect, unnecessary , improper or bad". Which makes you wonder why it took 2.5 months to get to that conclusion.

If you look at the original posts of the author, it turns out that there is a little bit more meat than the Enterprise Application Performance Problems Top 10 summary suggests. It seems that - when creating the summary - the article tipped over the point in which the "less is more" law no longer applies.

Johannes Brodwall

Posts: 19
Nickname: jhannes
Registered: Jun, 2003

Re: Vincent Partington's Enterprise Application Performance Problems Top 10 Posted: May 3, 2007 1:13 AM
Reply to this message Reply
> > In all these examples, the weakest link is the
> programmer.
>
> Cheap shot. The weakest link is the documentation.
>

Cheap shot. The weakest link is overly complex and no sufficiently valuable technology. And I'm not talking about databases.

"developers and application server administrators need to work together on this...": What! We need even more more specialized technology geek to pull our project off? I have never actually even needed that application server.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Vincent Partington's Enterprise Application Performance Problems Top 10 Posted: May 3, 2007 10:59 PM
Reply to this message Reply
> Cheap shot. The weakest link is the documentation.
>
> If something can be used rightly or wrongly and it is not
> obvious which is which, then there is an obligation to
> provide documentation that explains good and bad practices
> comprehensively and with brutal clarity.
>
> What we get instead is javadoc: reference documentation
> without context; necessary but not sufficient.

I don't think it is a cheap shot. If the documentation of a product is insufficient but the developer decides to use the product anyway, then the developer should be prepared to stand by (and justify) that decision.

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: Vincent Partington's Enterprise Application Performance Problems Top 10 Posted: May 4, 2007 8:27 AM
Reply to this message Reply
> I don't think it is a cheap shot. If the documentation of
> a product is insufficient but the developer decides to use
> the product anyway, then the developer should be prepared
> to stand by (and justify) that decision.

Likewise, a developer who decides to create a library or framework should be prepared to design and document it well.

I don't understand this attitude that all the responsibility for problems lies with the user of a technology but not with the creator of it.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Vincent Partington's Enterprise Application Performance Problems Top 10 Posted: May 4, 2007 4:51 PM
Reply to this message Reply
> I don't understand this attitude that all the
> responsibility for problems lies with the user of a
> technology but not with the creator of it.

Well, this argument could eat its own tail for ever, especially if lawyers were invovled but my take is this:

Whilst the creator of a product is resposible for the that product itself. The user of the product is responsible for the decision to use the product. There is a grey area related to bugs and defects in the product i.e. where the product doesn't do what the documentation says it does; but if the user is doing something not covered by the documentation then, regardless of whether or not it should have been covered, it's a user decision and therefore a user responsibility. I can't see a product user successfully arguing their way out of a problem by taking the line: "It's not my fault that I didn't really understand how this product worked, because it wasn't docmented properly.". Professional developers have professional responsibilities.

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: Vincent Partington's Enterprise Application Performance Problems Top 10 Posted: May 4, 2007 7:56 PM
Reply to this message Reply
Professional developers have
> professional responsibilities.

I agree with that statement whether those developers are creators of the technology or develop applications based on it. Nevertheless, we shouldn't let the responsibility of the latter group discourage us from evaluating and criticizing defects in the design or documentation of the former group.

We should keep in mind that those developers who are consumers of these technologies rarely have the luxury of choosing their personal favorite, so often their responsibility is limited to doing the best they can with a technology that is mandated by others.

It's also useful to document common problems and how to avoid them (which was the point of the article). The alternative is to simply say "don't use technology X because many projects using it fail".

Flat View: This topic has 11 replies on 1 page
Topic: What are Your Hibernate Cache Preferences? Previous Topic   Next Topic Topic: Consensus Reached on Java Closures Proposal

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use