Jboss AS 5 Performance Tuning

RickJWagner writes "20 percent inert ingredients, 80 percent nitro glycerin. That's how I'd describe JBoss AS 5 Performance Tuning from Packt. The first 50 pages are nothing to get excited about. This first chapter and a half describes the author's performance tuning life cycle methodology and introduces us to a handful of open source tools that can assist us in our tuning efforts. The tools section seems especially weak-- there are plenty of screenshots showing the tool's menu screens, something you'd normally pick up in about a minute from the tool's distribution website. Honestly, at this point I was beginning to wonder if this book was going to live up to my expectations. Luckily I pressed on for a few more pages, and hit the rich paydirt that makes up the rest of the book. From that point on, every section yielded valuable tuning advice." Keep reading for the rest of Rick's review. Jboss AS 5 Performance Tuning author Francesco Marchioni pages 312 publisher Packt Publishing rating 8/10 reviewer Rick J Wagner ISBN 184951402X summary A very good book on performance tuning in general and JBoss in particular. The author breaks the environment down into slices: Operating System, Application Server stack components, application code. Starting with the O/S, the book tells us the signs to watch for in various situations (i.e. how to detect and compensate for high or low utilization of the processor, or the disk.) The author explains likely causes for the problem, and what can be done about it.

Java programmers need to understand JVM tuning, and here it is given a whole chapter. This includes a lengthy explanation of how to correctly size your heap, followed by a nicely illustrated section on garbage collection, gc sizing, and choosing the best algorithm for your needs. All well done and very readable.

The book's subject is JBoss AS 5, and it's given a whole chapter, too. Thread pools and Connection pools are explained, as well as proper tuning of prepared statements and logging recommendations. Every programmer knows that logging can really drag performance down, right? Here we learn how to optimize it.

The middle of the book deals with JEE applications and the application server components that enable them. EJBs are given extensive coverage. JMS, a JEE hot-button, is also covered well. (Both JBoss Messaging and the newer HornetMQ are explained.)

The persistence layer is given holistic coverage. Starting with database design recommendations, the author proceeds to indexing, JDBC, connection pooling, and JPA/Hibernate. The Hibernate section is a good example of the kind of detail you'll find-- the author explains caching (first and second level) and the considerations you'll want to make to optimize their usage. Besides tuning the application server parts, there are recommendations for your application code, too. Hopefully you've bought into the recommendation to tune your code all throughout the development life cycle. If not, well, too bad for that one. Ditto for the database design.

One of the things JBoss makes really easy is clustering. Note: I didn't say cluster tuning, I said clustering. To optimize clustering, you'll have to understand all that low-level networky stuff like ethernet flow control and UDP buffer sizing. (I'm guessing this is not something your garden-variety developer thinks about every day, and make specific mention here as a demonstration of the kind of depth you get in this book.) Besides these bottom-layer concerns, the book also covers higher level parts of the stack like JGroups and JCache configuration, replication, and tuning cache storage. Unless you're really, really a bit-head, all that probably sounds a little deep. But the book explains it all in a way that makes it understandable and approachable.

JBoss uses Tomcat for it's web server tasks, so Tomcat is given good coverage as well. Nothing here seems JBoss specific, so most any Tomcat user could benefit from this part of the book. Connector configuration, thread pool sizing, and the Apache Portable Runtime are included. JBoss web server integration with Apache introduces us to mod_jk, mod_proxy, and mod_cluster. As throughout the book, the author uses JMeter to capture metrics to demonstrate to us the kind of performance we might get from each.

The final technical chapter deals with web application frameworks and web services. Web applications seem especially tunable in the development stage, while web services get code construction tips as well as configuration hints. The book ends with one more suggestion to make performance tuning part of your every day life rather than something crammed in after deployment time.

Like many technicians, I respect technical knowledge. This book is crammed full of it, and it's all presented in a readable manner. What's the bottom line? I'd recommend this book to any JBoss user (strongly), any JEE developer (with little reservation, especially Tomcat users), or any Java coder (who has a little extra money to spend.) Anyone else can probably live without this book. But if you're running JBoss (and you're technically minded), spend the money, you'll be glad you did.

You can purchase Jboss AS 5 Performance Tuning from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Once again 8/10

[Anonymous Coward]

How many /. book reviews end up 8/10.

Review some books that suck so we can avoid them please!

Re:Once again 8/10

[Lunix Nutcase]

Packt Publishing: Check
Rick J Wagner: Check
8/10 Score: Check

This is just another shill review bought and paid for by Packt Publishing.

Re:Once again 8/10

[Monkeedude1212]

I give this post a 2/10.

Rebasline

[garyisabusyguy]

If your average is 8/10... then change those all to 5/10

That should create more headroom in the upper range and provide for more clarity in the reviews.

Or just rate everything at 8/10 so the authors can be happy that they are 'above average'

Re:Memory Management

[Lunix Nutcase]

Java at no point specified that there wasn't going to be any memory management at all.

O rly?

Under section 2.1.6 Memory Management and Garbage Collection and I quote:

Java technology completely removes the memory management load from the programmer.

This white paper was written in 1996 by James Gosling and Henry McGilton. M-M-M-MONSTER FAIL!

Re:Memory Management

[Curunir_wolf]

Under section 2.1.6 Memory Management and Garbage Collection and I quote:

Java technology completely removes the memory management load from the programmer.

This white paper was written in 1996 by James Gosling and Henry McGilton. M-M-M-MONSTER FAIL!

What, you don't know the difference between a "programmer" and a "system administrator"?

Re:Memory Management

[Rary]

Java technology completely removes the memory management load from the programmer.

Do you not understand what the bolded words mean? Gosling never claimed that Java would turn memory into this magical unlimited resource. Memory management is handled by the JVM, as opposed to by the code. This means that developers do not need to deal with memory management, but administrators do. In other words, don't worry about memory management when you're writing the application, but do worry about it when you're deploying it.

Don't blame "butthurt Java weenies", as you so eloquently put it in multiple other posts, for the fact that you don't understand the difference between a programming task and a deployment/administrative task.

All I can say is

[rainmayun]

I wish I had known about this book three years ago. Built that system, went through four releases, and moved on. God bless whoever has to maintain it now. But my biggest performance issues were from underdocumented 3rd party vendor APIs - black box JARs that did whatever the hell they wanted to, and a bunch of headscratching from the vendor when the damn things locked up.

performance tunning Jboss?

[TheDarkMaster]

How to get more performance from Jboss? Throw then away and use Apache Tomcat :)

Re:performance tunning Jboss?

[TheDarkMaster]

Well, I've used both in some applications and after a while I came to the conclusion that comparing Jboss with Tomcat is like comparing a whale to a sardine. And then I discovered that most of the features that I might need JBoss could be done by myself, the obvious choice was to stay with Tomcat for performance.

Re:Memory Management

[JonySuede]

And if you read the parent post it addresses your concern:

Specific to your troll, though, is that in fact the programmer DOES NOT need to do memory management beyond the basics of "don't keep allocating resources and never release them" (specifically database and file handles). The JVM itself does all the management beyond that. This article and book refer to tuning the JVM and J2EE server, which run the programmers code. The programmer shouldn't give a fig how the container is tuned beyond common sense.

Re:Memory Management

[Rary]

The initial claim in this thread was that Java was supposed to eliminate all memory management entirely. Shayde responded that this was never claimed, but rather that it would remove most of the memory management responsibility from the programmer. You quoted him as saying (emphasis mine):

Java at no point specified that there wasn't going to be any memory management at all.

You responded to that quote with a quote from Gosling that actually stated exactly what he had said, which is (again, emphasis mine):

Java technology completely removes the memory management load from the programmer.

I explained that the point of Gosling's comment, and likely Shayde's comment as well, is that the programmer does not need to worry about memory management, because it is handled by the JVM and therefore configured at deployment time by an administrator.

So, now I'm confused. Are you agreeing with Shayde, or disagreeing with Shayde? Because your quote from Gosling agrees with him, yet you use it to argue against him. And I agree with him, yet you seem to not disagree with any point I've made. So what exactly is your point? Do you believe that it was ever claimed that Java would eliminate all memory management entirely?

Re:Memory Management

[ratboy666]

Why would an object reference be a pointer? A more useful construct would be an index to a pointer; then the object can be moved and all pointers would still be valid. Or, possibly a hash.

Anyway, I would definitely shy away from making an object reference even APPEAR as a valid pointer. The benefit is that "cracking" a system, and supplying an object to an OS level routine just wouldn't work. (eg. Put all object references in one 32 bit space, and map that as read-only). Characters and smallints can live in object reference space "as-is", everything else would need the double indirection. Yes, performance may suffer a bit, but wouldn't the system be more robust?

And, as a side-benefit, any low-level code introduced would be forced to use the correct access mechanisms, making it more likely to be portable.

Re:Memory Management

[tpv]

Right. But server administrators are not programmers.

Nothing (*) in the Java Language Environment (which is what the linked document covers) requires the programmer to do explicit memory management.
Optimally tuning your system requires additional knowledge beyond the language environment. That's true in every system.

CGI removed the need for developers to understand the implementation details of HTTP and TCP/IP, but if you want to tune your web-server, then you're going to need to understand those.
"Everything is a file" is all well and good for a C/Unix developer, but the system administrator needs to know the difference between the kernel parameters for TCP/IP and for Disk I/O.
SQL developers care about tables and indexes and queries and don't need to worry about physical storage or the number of execution engines, or the size of the procedure cache, but DBAs need to care about all those things.

If you somehow believed that because "Java technology completely removes the memory management load from the programmer", then no one was ever going to need to think about how much memory was used by a system built in Java, and somehow system administrators could run large Java applications without even thinking about how to tune them, then I don't know what I can say to help you.

Yes, for good or bad, Java removes memory management load from programmers - but it does not remove it from administrators, and I'm not aware of any documentation that claimed it would.

(*) Direct memory buffers (which were added long after that document was written), allow the programmer to do some memory management if so desired, but they are still not required

Re:Memory Management

[tpv]

While I agree with your argument about the difference between the programmer and the administrator, the original book review says:

Java programmers need to understand JVM tuning, and here it is given a whole chapter

which is a poor choice of words from the reviewer.

Programmers don't need to understand JVM tuning. Administrators do. A lot of the time 1 person will perform both roles, but they are still different roles.

Of course, I'm not sure how that poor choice of words on the reviewers behalf justifies Lunix Nutcase's rants.

Ass Performance - must be Java

[BestNicksRTaken]

Did anyone else read that as "JBoss ASS Performance"?