Jboss AS 5 Performance Tuning 45
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.
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.| 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. |
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.
Re: (Score:2)
Re: (Score:2)
Wow modded flamebait while not being flamebait at all and being 100% correct about Java history? There really must be butthurt Java weenies lurking this thread to downmod.
Re: (Score:2)
In reality, Java Memory Management is quite complex and widely misunderstood.
Most often by Java programmers and evangelists themselves.
Re: (Score:2, Interesting)
Java at no point specified that there wasn't going to be any memory management at all.
O rly? [sun.com]
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 (Score:4, Insightful)
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: (Score:2)
If I even do get a reply from them I look forward to a Bill Clintonesque "that depends on what the definition of is is" type comeback.
Re: (Score:3)
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
Re: (Score:2)
Do you not understand what the bolded words mean?
Yes, I do. It says that a programmer is completely removed from having any memory management load. This goes in direct contradiction to the statement:
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).
Gosling never claimed that Java would turn memory into this magical unlimited resource.
And no one claimed he said anything of the sort. Where exactly did anyone make such a claim? Not me.
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.
That's great. But the person I was replying to was talking about the programmers not the administrators so I don't see what relevance this has to anything. The word administrator is not even present at all in Shayde's post.
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.
Which is great, but wasn't the cl
Re: (Score:3)
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
+1 agree (Score:2)
you some it up more eloquently than I ever could.
Re: (Score:2)
sum it up
me and my orthophonic spelling
Re: (Score:2)
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
Re: (Score:3)
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: (Score:2)
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.
"E
Re: (Score:2)
What next? Pointers?
Well to be fair, object references are pointers you just aren't allowed to do things like pointer arithmetic on them.
Re: (Score:3)
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
Re: (Score:2)
Why would an object reference be a pointer?
Because it's faster to only copy a 4 byte pointer to an object instead of the entire object which could possibly be many magnitudes larger?
Re: (Score:2)
But why is the reference a POINTER?
How about an implementation that uses (say) 4 bytes for an object reference. But directly encodes small integers and characters up to +/- 2 ** 30, if the upper bit is zeroed (31 bit integer). If the upper bit is one, the lower bits can represent an index into a pointer table, which can, in turn be a 64 bit pointer.
This would allow efficient representation of up to 2 ** 64 bytes of object space, and a unified efficient representation of self-representing integers and charac
Once again 8/10 (Score:2, Interesting)
How many /. book reviews end up 8/10.
Review some books that suck so we can avoid them please!
Rebasline (Score:3)
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:Once again 8/10 (Score:4, Interesting)
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: (Score:2)
Re: (Score:2)
Re: (Score:2)
I checked in case this was a troll, but no, he's right. Look at Mr. Wagner's posts tagged 'Book Review' [blogspot.com]: they're all reviews of Packt books.
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
I give this post a 2/10.
Re: (Score:2)
All I can say is (Score:3)
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? (Score:3)
Re: (Score:1)
Now if you meant to say 'throw away Java EE', then perhaps you had a point, depending on the actual use cases.
Re: (Score:3)
JBoss AS5? (Score:2)
Re: (Score:2)
Riiiight! I'm so not following that link! Are the trolls not even trying to hide their goatse links anymore?
You've been Rick Holed!
Ass Performance - must be Java (Score:3)
Did anyone else read that as "JBoss ASS Performance"?
Re: (Score:1)
What are JBoss (Score:1)
I did the Googol and found. "20 percent inert ingredients, 80 percent nitro glycerin" is good. Where can I find supplier of this JBoss materials, I can pay top American dollar.