Optimized Development for WebLogic Portal Apps

If you would like to improve the speed at which you can develop a WebLogic Portal 9.2 application, this blog is for you. Actually, most of this advice applies to anyone developing medium to large Java web applications, but I will focus on WLP. Across BEA we have been investigating ways to improve what we call iterative development performance. I will share some discoveries that you can put to use today.

NOTE: this blog entry was originally posted May 12th, 2007 on my previous blogging system (dev2dev.bea.com).

The 5 Easy Ways to Improve Development Performance

I will explain the 5 tips we have found to be most useful in improving iterative development performance. Performance here is measured in the time it takes to republish your application. These tips have been measured with WebLogic Portal applications, but any medium to large JEE applications will likely see the same benefits. They are, in order of importance:

1. Use JRockit as your server JVM!!! It's faster and won't fall over due to PermGen issues like Hotspot.
2. Use Parallel Garbage Collection with JRockit - up to 40% improvement!
3. Don't start Autonomy search services unless you need them. This saves 500MB of RAM.
4. Prefer developing classes in web application scope. Workshop has nice optimizations if you do this.
5. Avoid bloating your application with unnecesary files. Consider relocating static files to a web server.

Details for each follow below.

BEA JRockit is your Friend

This one is a no-brainer. We have found JRockit to be both faster and more stable than Hotspot for iterative development. When creating a new domain, always select JRockit as the JVM for the server (Hotspot is the default, so you will need to take action). If you have seen out of memory errors after republishing a number of times, switching to JRockit will solve that problem for you. Note: Workshop IDE is configured to run on Hotspot, and that's ok so don't try changing that. Only change the server JVM.

Not sure what you are using? Look at the server console at startup and it will log whether is using Hotspot or JRockit. To configure JRockit for a domain, set JAVA_VENDOR=BEA in the setDomainEnv.(sh,cmd) script in your generated domain.

JRockit is a good choice not only for performance reasons. Henrik Stahl blogged about other features that make JRockit a good choice for development.

Life is Better in a Parallel Universe

Another no-brainer. Do you want up to 40% improvement in the speed of a republish? The Parallel algorithm for garbage collection in JRockit just does a great job with this type of action. Parallel can increase pause times, but overall it maximizes throughput. Maximum throughput sounds like something you want!

To configure parallel GC for your server, you need to alter setDomainEnv.(sh,cmd). Change the line that says MEM_ARGS="-Xms256m -Xmx768m" so that it read MEM_ARGS="-Xgc:parallel -Xms256m -Xmx768m". Then light a cigar, kick your feet up, and call your wife to tell her you expect to finish work early today.

Save the Soul Searching for Production

This one is WLP specific. WLP is preconfigured to start the Autonomy search engine out of the box. This is so full-text search across the content repository will work for you. However, most developers don't need to be doing full-text search in their environments. Autonomy takes up quite a bit of RAM, so it's a good idea to disable it unless you need it.

You will need to edit your DOMAIN_HOME/bin/startWebLogic.cmd/sh. Edit the file so that the default search profile is set to "none", by updating this line:

if "%CONTENT_SEARCH_OPTION%"=="" (
	@REM make the following assignment to none, so it won't start Autonomy
	set CONTENT_SEARCH_OPTION=none

That's Why We Love Workshop

Workshop is smart, so let it be smart and help you out. When developing an application, you ultimately have 3 scopes in which to deploy your artifacts:

• System classpath - please avoid this, for a variety of reasons.



• Application scope - EJBs are deployed in here, and anything else that needs to be shared across multiple web applications.



• Web Application scope - everything deployed in the web project is in this category.

If you change a class deployed on the system classpath, you need to restart your server. Not a good option at all. If you change a class deployed in the application, Workshop will need to redeploy the application and all web applications. This can be expensive. If you change something in the web application, Workshop can generally just redeploy the web application. That's the fastest way to republish. So if you can, prefer to deploy your development artifacts in a Web Project.

Workshop has more features to help speed you along, so visit this page for more info.

Put that 100MB Movie on YouTube

Size does matter when it comes to deployment. Especially in development, avoid bloating out your application with static files that could be located elsewhere. A modest amount of images, CSS, and Javascript in your application is inevitable, but consider using Content Management or a web server to host large collections of stuff.

Work Continues...

A special thanks goes out to the WLP engineers (Dave, Bret, thanks!) who provided the above information. They have been analyzing iterative development, and continue to look at ways to make WLP application development faster. Also, Josh Lannin blogged about more performance tips for WLP developers in this blog entry. Hopefully you can put these tips to work for you on your current projects!

Technorati Tags: weblogicportal,performance,jrockit