Xebia Blog

Last week we discussed #6 - which means we've now passed the halfway point of SOA Pitfall countdown! Let's quickly move on to #5.

Like the Not Invented Here syndrome we discussed earlier, Big Design Up Front (BDUF) is something not only witnessed within the realm of SOA. However, where the NIH syndrome is generally accepted to be a bad thing, things are not that simple when it comes to BDUF.

(more...)

Filed under: Agile, Architecture, SOA
2 Comments

At Xebia we are involved in quite a number of Service Oriented Architecture (SOA) projects, from small to big. In that capacity we see a lot of good stuff happening, but we also encounter quite a number of projects that have stalled or failed.

To share our experiences with these SOA projects, Gero Vermaas, Viktor Grgic, Rik de Groot, and myself have decided to write a series of blogs about the most annoying pitfalls of SOA. Each week we will be publishing one item from the list. This way we hope to spread awareness of these dangers and also provide you with a checklist of what to watch out for. Of course, as is always the case with these kinds of lists, they are not complete and not all the issues are as absolute as the title may imply. YMMV!

The first item we want to discuss is the Not Invented Here Syndrome (NIH). Of course this is something that can be witnessed in more areas of IT, but in a SOA context it actually applies on two different levels.
(more...)

Filed under: Architecture, SOA
4 Comments

For the last two and a half months, I've been blogging about the Enterprise Java Application Performance Problems Top 10:

• #10 - Excessive logging
• #9 - Incorrect application server configuration
• #8 - Incorrect usage of Java EE
• #7 - Unnecessary use of XML
• #6 - Improper caching
• #5 - Excessive memory usage
• #4 - Badly performing libraries
• #3 - Incorrectly implemented concurrency
• #2 - Unnecessary remoting
• #1 - Incorrect database usage

(more...)

Filed under: Java, Performance
4 Comments

I'll keep you in suspense no longer. It's time for numero uno of the EJAPP Top 10 countdown!

Somewhat unexpectedly for an Enterprise Java Application Performance Problems Top 10, the #1 issue is the incorrect usage of databases.

(more...)

Filed under: Java, Oracle, Performance
3 Comments

Picking up the pace to make sure I get the countdown finished before I go to JavaOne ;-), I'll quickly move on to #2 of the EJAPP Top 10 countdown....

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.

(more...)

Filed under: Java, Performance
4 Comments

We've reached the top 3 of the EJAPP Top 10 countdown now, so let's get going...

Incorrectly implemented concurrency can cripple the performance of your application in very unpredictable ways. Applications that perform pretty well under light load may crawl to a halt under heavier load.

A major cause is lock contention, which only becomes an issue when multiple threads are involved. For example, if a request that takes 100ms, spends 25ms in a critical section, no more than four requests can be handled every 100ms. No matter how much you decrease the other 75ms, Amdahl's law tells us the maximum speedup by introducing parallelization is 4!

(more...)

Filed under: Java, Performance
1 Comment

After skipping the easter weekend to go snowboarding in Chamonix, I'll continue the EJAPP Top 10 countdown with number 4.

Badly performing libraries are a problem that occurs more often than one would expect. This issue is somewhat similar to the incorrect usage of Java EE in that not enough care is taken in selecting and using a certain technology. 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

(more...)

Filed under: Java, Performance
2 Comments

We've covered half of the EJAPP Top 10 now. Now let's start with the second half!

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.

Both can be problematic, not because of the allocations themselves but because of the effect on the garbage collector. Luckily garbage collection performance is improving with every JDK release.

(more...)

Filed under: Java, Performance
1 Comment

Let's continue the EJAPP Top 10 countdown with number 6.

Caching is a funny thing. 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. Improper caching covers both cases.

(more...)

Filed under: Java, Performance
7 Comments

Last week we discussed the incorrect usage of Java EE in the EJAPP Top 10 countdown. After that very broad topic, it's time for a very specific one on number 7.

The unnecessary use of XML is a boon to the performance of your Java EE application. 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:

• as a configuration file format, e.g. Java EE deployment descriptors and Spring configuration files,
• as a remoting protocol, e.g. SOAP or Burlap, and even
• as a data storage format, e.g. Apache Xindice and eXist.

Someone once said that "XML is the noun and Java is the verb" and that has caught on. Unfortunately XML processing is heavy on CPU cycles and on memory usage.

(more...)

Filed under: Java, Performance, XML
No Comments