Over the past several years, the Web Architecture team at NBC Universal Studios has dedicated a significant amout of their time and resources to improving the performance of their highly distributed enterprise architecture. In this multi-part series, Richir Choudhry, Alpesh Vaghela and Vaidyanathan Kothandaraman will be sharing their insights, tips and the best practices they employed during their efforts to enhance application performance without actually editing or refactoring any of the production code.

Best Practices for Optimizing Your JBoss EAP Production Environment

This is the first in a multi-part series that will delve deeper and deeper into how to configure your JBoss environment for optimal performance.

All of the points that were made in this article, are pretty much common sense for the experienced architect.

 

So. What else is new.

If there were no articles like these when you had been becoming an architect, you wouldn't have become one. There are always newcomers to every industry who value articles like this one, which leads to conclusion that you are actually lacking common sense since you missed that tiny fact.

I'm really tired of TSS posting weak technical articles. There was a time when TSS had some worth while papers and comments. If novices need guidance, there are a myriad of forums out there to assist. But,hey chief if you want to turn this into a smack talking exhibition. Bring it. You'll lose.

 

I agree with you completely, it was a waste of my time reading it even though i have virtually no JBoss experience.

How can you say, its not worth reading when you have no idea of Jboss? Also the article is not even fully published? Its like with the books heading you are defining the total content of the book. I think first we must read the full article and then pass judgment on it. In addition to the above you must learn from this article and see what you can take and what you can leave.

 

Pax et bonum :-)...

If you are tired of weak technical articles then why don't you write one and enlighten us with new and creative content in mature industry like ours. If you are not paying to TSS for their service you don't have any moral grounds to bitch and moan, and to slam down other people's work.

Under most circumstances, I would have said that the author of an article should have been given due credit for writing an article, and it is easier to slam an article versus writing one.

However, after having read the article, I cannot help but agree with Jeff. Alot of the things being mentioned are the most basic elements. It is not really ground breaking. I have been visiting theserverside.com for almost 6 to 7 years now. When I first came to this site, the articles were informative, interesting, and a great source for learning something new.

Nowadays, it seems to have lost that edge. It seems to be more tuned towards announcing product launches, and having articles which do not really seem to go very far. 

I mean, just look at the article. Using "info" verbosity for logging messages. I do not think any sane person would choose to deploy an application into production with either trace or debug levels of verbosity. Another suggestion to start JBoss in production mode. If the server is deployed into production mode, why would you not configure it to be run in production mode. 

In almost all environments I have worked in, we turn off hot deployment. This is for a very simple reason. We do not want someone accidently doing something that causes an app to be deployed automatically and screw up everything. 

Using the latest JVM. Common sense. Every new release of the JVM comes with performance improvements and enhancements. Keeping your OS patches up to date is also common practice in most environments I work in. Fundamentally, our vendors will not provide support on the OS if we are not already updated to the latest fix packs. 

In general, alot of the points raised in this article are common sense. Not something worthy of being the kind of article I would expect from theserverside.com

"Alot of the things being mentioned are the most basic elements."

It is basic because in matured and commoditized industry there is not much new you can say which hasn't been said 1000s times before.

 

"for almost 6 to 7 years now"

Like I said, there are thousands of new developers entering our industry who are yet to learn the business. And they are beginners now just like you were beginner 7 years ago. Just because you may not be the target audience of this article, does not mean this article does not provide any value.

If you have mastered this content, then skip it, no need to insult other people's effort.

 

Chief,

I do agree with you. Personally, it is also great to review things you already know or hear it from someone else. That all being said, I do have to say the authors could have made a little more effort to put in points that are perhaps non-obvious in addition to the common (albeit important) ones.

Cheers,

Reza

So, this is just the introductory article. The tips here are indeed pretty high level.

The next article or two will get into some actual tweaks and tests on various configuration parameters of the JVM, picking up on a few of the points mentioned in this article about performance tuning. I think you'll see some of the more interesting and in depth optimization suggestions that you crave.

Maybe tagging threads as beginner/intermediate/expert type of thing. That would allow people to pre-filter entries before reading on.

FIrst off Chief. Don't tell me what are, and are not my rights. You don't make any rules, or , laws here. Anyone has the right to comment how ever they see fit, as long as its not a personal attack on the authors. So. Think whatever you want. I'm going to continue to comment on articles/papers, as I see fit. I think the TSS either needs to segment the offering they present into  categories such as (Novice,Intermediate,Expert), or do a better job a screening these papers. The article in question here, creates a lot of "noise" for experienced developers, much like spam.

It too early to pass such remarks Jeff, the article is not even fully published?

As others have remarked, it's indeed a very basic article (maybe the next articles in the series will be more comprehensive) but that's fine. We're all beginners at some point. More worrying is that I think at least two points in the article are misleading.

- Use trimmed version of Web Server (Apache2.2.8, 2.2.15), by compiling it specific for the needs of the applications or env.

- Trim the application server (Jboss EAP 4.3) by exactly using what you need from the application server

 

Both of these tasks can consume A LOT of time and will require comprehensive testing and validation, while delivering very, very questionable returns. It's sub-optimization at best, no effect most likely and regression-hell at worst. Unused app-server modules consumes a nominal amount of hdd space, but I challenge you to show me unused modules consume and CPU cycles or enough memory to have any impact whatsoever. I'm inclined to even call this a pit-fall for fresh architects, wasting effort on something that should be the very last item of your to-do list just to say you did.

I could have replaced JBoss with any other servername in the article , and it would still have been valid.

I was disappointed to get no real value out of this article . However , trimming down apache and JBoss seemed to be interesting approaches. Will definitely look forward to see articles on these two topics , if  its in the pipeline.

 I think this article is very inspiring to me and my team, as I have worked with Jboss323, and jboss404 for atleast 5 years in a truly ennterprise env and it makes perfect sence to me. I would like to see the details of this article and then come to a conclusion.   I think commenting on it without seeing the facts will be jumping the gun.   Please provide the details asap.

Combination of Apache and Jboss is a very good distributed Architecture and it makes the landscape of enterprise systems as per the web and middleware layer is considerd. Its very very difficult to find the exact match and see what is best to the application. If this article provides a indepth we would like to see how it helps the community and overll to the J2EE and apache landscape.  

Tweaking apache and recompiling it to perfection can take months and it not at all easy, apache gives you a lot of flexibility but at the same time if its not done right it may make your system crawl  

JVM: Again this is also very complex, and can take a lot of iterations to come to a right mix, lets see what this artical can suggest us and we can surly improve by the experience of others  

JbossEAP4.3:  is a major ugrage to the older version of Jboss as its adds lots of other components like seam, jbpm and so on an so fourth. In my experience trimming certainly helps to improve the performance, and its Jboss recommendations.   Now comming to general guildlines: Most of you know all the jvm and apache setup, now tell me how many can do it right first time ?  the answer is very few, if this arcitcal give us some guidelines I think it will be perfect. We can always club it with our knowledge and experience and make it better.   Hats off to the TSS team. "We must see such real world example rather just a theory"

First of all let me thank the TSS team and the people who are involved in this article.

 

I along with my team at Infosys worked on similar project with apache as a front end and Jboss 5.0 as a middle layer, and we had lots of challenge. We would be happy to see how this article simplifies the performance tuning of both apache and Jboss.

 

What are the settings they have used for both Apache and jboss how are the JVM parameters adjusted, with what type of underlying hardware.

 

How the testing was done? What was considered and what was left out and why?

 

What was the load? What were the outcomes?

 

If this article provides us this much also, I would take some of the learning and use it as a best practice (only after testing it in our setup), in our enterprise soln which we are designing for various customers, all across the globe.

these best practices should be put into good use

gift ideas for illustrators

indeed for the benefit of programmers monroe dimaggio