Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Jboss AS 5 Performance Tuning

samzenpus posted more than 3 years ago | from the read-all-about-it dept.

Books 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.

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.

cancel ×

45 comments

Sorry! There are no comments related to the filter you selected.

First Post! (0)

Anonymous Coward | more than 3 years ago | (#34619680)

EOM

Memory Management (0, Insightful)

Anonymous Coward | more than 3 years ago | (#34619692)

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.

Wait? Memory management? Java? Gee, Java was supposed to eliminate all those for the programmer.

What next? Pointers?

Re:Memory Management (1)

Shayde (189538) | more than 3 years ago | (#34619864)

You might want to read up on your Java Memory Management misconceptions. Java at no point specified that there wasn't going to be any memory management at all. Just that memory management for bad programmers was being handled automatically via garbage collection. In reality, Java Memory Management is quite complex and widely misunderstood. Instead of just 'flat memory space that we just keep malloc()ing until we use it up', the memory manager has tiers of usage, that are used for immediate, short term, and long term storage. 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 (0, Flamebait)

Anonymous Coward | more than 3 years ago | (#34620086)

You might want to read up on your Java Memory Management misconceptions. Java at no point specified that there wasn't going to be any memory management at all. Just that memory management for bad programmers was being handled automatically via garbage collection.

In reality, Java Memory Management is quite complex and widely misunderstood. Instead of just 'flat memory space that we just keep malloc()ing until we use it up', the memory manager has tiers of usage, that are used for immediate, short term, and long term storage.

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.

Wrong.

When Java was first introduced, SUN said explicitly that all memory management will be handled by the JVM.

Troll?!? Nonsense. You on the other hand, are ignorant of Java history.

Re:Memory Management (1)

Lunix Nutcase (1092239) | more than 3 years ago | (#34620546)

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:Memory Management (1)

Lunix Nutcase (1092239) | more than 3 years ago | (#34620314)

In reality, Java Memory Management is quite complex and widely misunderstood.

Most often by Java programmers and evangelists themselves.

Re:Memory Management (2, Interesting)

Lunix Nutcase (1092239) | more than 3 years ago | (#34620404)

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 (-1, Offtopic)

Lunix Nutcase (1092239) | more than 3 years ago | (#34620512)

Troll? Really? Looks like there's a butthurt Java weenie with mod points lurking.

Re:Memory Management (3, Insightful)

Curunir_wolf (588405) | more than 3 years ago | (#34620620)

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 (1)

Lunix Nutcase (1092239) | more than 3 years ago | (#34620694)

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:Memory Management (2)

Rary (566291) | more than 3 years ago | (#34621176)

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.

Re:Memory Management (1)

Lunix Nutcase (1092239) | more than 3 years ago | (#34621412)

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 claim made by the person I was replying to.

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.

But the person I was talking to specifically mentioned programmers not administrators. Maybe you need to learn how to read?

Re:Memory Management (2)

Rary (566291) | more than 3 years ago | (#34621584)

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?

+1 agree (1)

JonySuede (1908576) | more than 3 years ago | (#34621618)

you some it up more eloquently than I ever could.

Re:+1 agree (1)

JonySuede (1908576) | more than 3 years ago | (#34621834)

sum it up
me and my orthophonic spelling

Re:Memory Management (2)

tpv (155309) | more than 3 years ago | (#34622914)

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.

Re:Memory Management (0)

Anonymous Coward | more than 3 years ago | (#34624338)

When you're in a hole, quit digging. It's pathetic.

Java's memory claim was a lie.

Re:Memory Management (2)

JonySuede (1908576) | more than 3 years ago | (#34621526)

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 (2)

tpv (155309) | more than 3 years ago | (#34622860)

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 (1)

Lunix Nutcase (1092239) | more than 3 years ago | (#34620292)

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:Memory Management (2)

ratboy666 (104074) | more than 3 years ago | (#34622368)

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 (1)

Lunix Nutcase (1092239) | more than 3 years ago | (#34632852)

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:Memory Management (1)

ratboy666 (104074) | more than 3 years ago | (#34698550)

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 characters, and allow up to 2 ** 30 objects.

In the memory space used by the OOP programming system (running 64 bit), map the entire first 4GB to "not accessible".

And, the object space can be completely separate, and not directly reachable or corruptible AND an "object reference" would not be usable as a pointer to subvert the type system.

Just saying... I would prefer that sort of design. As a nice bonus, memory could be completely reorganized without invalidating any object references.

And, you still have the property that only 4 bytes needs to be copied instead of an entire object. Note that Windows uses this sort of design -- the object reference is called a HANDLE.

Once again 8/10 (2, Interesting)

Anonymous Coward | more than 3 years ago | (#34619868)

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

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

Rebasline (2)

garyisabusyguy (732330) | more than 3 years ago | (#34620048)

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 (3, Interesting)

Lunix Nutcase (1092239) | more than 3 years ago | (#34620198)

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 (0)

Anonymous Coward | more than 3 years ago | (#34621420)

I'm still not totally convinced that Rick J Wagner is a real person.

If he is real, he has a truly unbelievable amount of experience in all kinds of topics judging by how he can bring it to bear when reviewing all kinds of books.

Re:Once again 8/10 (1)

RickJWagner (1297357) | more than 3 years ago | (#34622954)

Gee, thanks. (I think.) No, seriously, I'm a real-life code slinger and have been doing it for over 20 years. Am I an expert in every topic I write about? Sadly not. But if the topic is in the enterprise arena, there's a good chance I've got some hands-on experience there. I always try to call 'em like I see 'em, whether I've been working with the tech stack 15 years or 15 days. Thanks, Rick

Re:Once again 8/10 (1)

RickJWagner (1297357) | more than 3 years ago | (#34622962)

P.S. Validate my existence at www.rickwagner.blogspot.com. If you're feeling especially generous, click one of my ad-sense links. Though I've never cashed in yet, I think I get something like a dime for every million clicks! Or something like that...

Re:Once again 8/10 (0)

Anonymous Coward | more than 3 years ago | (#34621770)

I just found this guy's blog

http://rickwagner.blogspot.com/2010_10_01_archive.html

unsurprisingly it's all about Packt

Re:Once again 8/10 (1)

ElMiguel (117685) | more than 3 years ago | (#34622450)

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:Once again 8/10 (1)

RickJWagner (1297357) | more than 3 years ago | (#34622826)

You are correct, my personal blog has been heavy on Packt titles. But if you check other sources online, you'll find other reviews for other publishers. The common theme? Tech topics... (Packt has nicely asked if I'd post on my blog, others have not.) If you're really a glutton for research, hop out to Amazon where you can find "Data Engineering: Mining, Information and Intelligence". I actually got to write a few lines in that one! Rick

Re:Once again 8/10 (1)

RickJWagner (1297357) | more than 3 years ago | (#34622764)

A good checklist, but you're totally wrong on the last point. I have never received a dime from Packt or any other publisher. (I did two reviews for Manning recently, for instance.) My total compensation? Sometimes a print copy of the book, sometimes an e-copy. I just like to keep current on tech topics, so I do a lot of reading. Rick

Re:Once again 8/10 (2)

Monkeedude1212 (1560403) | more than 3 years ago | (#34620548)

I give this post a 2/10.

Re:Once again 8/10 (1)

RickJWagner (1297357) | more than 3 years ago | (#34622734)

Well, I guess you're right, I probably am a little heavy on '8's. But there's a reason-- I get to pick the books I review, so I tend to pick ones that I'm going to like. (Why aren't there any 10s? I guess I haven't found the perfect book yet.) I would say that if I do any reviews in the future I'll try to throw in more variety, but I really don't see it happening. (I'm going to pick books that I like....) so I'd say please just read the reviews (they're honest) and make your own numeric rating. Rick

Re:Once again 8/10 (0)

benthurston27 (1220268) | more than 3 years ago | (#34625638)

Is it possible that you don't even know you're a shill? How deep does this rabbit hole go? J/k

All I can say is (2)

rainmayun (842754) | more than 3 years ago | (#34621294)

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? (2)

TheDarkMaster (1292526) | more than 3 years ago | (#34621476)

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

Re:performance tunning Jboss? (1)

ByteSlicer (735276) | more than 3 years ago | (#34623270)

JBoss is built on top of Tomcat. Tomcat doesn't have support for Java EE applications. If all you need is a servlet container, then by all means use Tomcat.
Now if you meant to say 'throw away Java EE', then perhaps you had a point, depending on the actual use cases.

Re:performance tunning Jboss? (2)

TheDarkMaster (1292526) | more than 3 years ago | (#34624030)

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.

JBoss AS5? (1)

BluBrick (1924) | more than 3 years ago | (#34623558)

Riiiight! I'm so not following that link! Are the trolls not even trying to hide their goatse links anymore?

Re:JBoss AS5? (1)

nacturation (646836) | more than 3 years ago | (#34626114)

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 (2)

BestNicksRTaken (582194) | more than 3 years ago | (#34623658)

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

Re:Ass Performance - must be Java (1)

MrLeekun (1964192) | more than 3 years ago | (#34650066)

I quite agree to your opinionCopy phone [0086-it.com]

What are JBoss (1)

Anonymous Coward | more than 3 years ago | (#34623912)

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.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>