Saturday, May 12, 2007

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!



5 comments:

Mike Morris said...

Peter, I liked your article. We're stuck with WLP 9.2.1 on a project and are in the process of application performance tuning. Our VM is Hotspot 1_5_04 and I was wondering whether the latest Sun Hotspot VM will work ok and also whether we can switch to JRockitt. We're using Solaris 10 - not sure if it's available on that platform? -- thanks.

Anonymous said...

Hi, There are different ways beyond the portal framework itself to improve the throughput with 10x and to decrease the time for the browser to build up a portal page. A lot is related to browser & page cache. At Componence we have specialized in Weblogic Portal, but you can easily use the tips and tricks for any portal.

Feel free to read more: http://hhvo.wordpress.com/2008/11/01/continuously-pursuit-to-optimize-weblogic-portal-performance/

Peter Laird said...

@smugboy Here is the link to the supported JVMs for WLP 9.2:
http://edocs.bea.com/platform/suppconfigs/configs/solaris/solaris10_92.html

@hhvo Thanks Ha. Nice article.

viswanadh said...

Hi Peter, my name is Viswa. I like your blogs.I would like to request you,that I am trying to learn weblogic portal 10.3. But there is no proper tutorial or kind of examples in weblogic (oracle) site.I am not expecting any spoon feeding kind of work.

If we see the tutorial in weblogic portal 10.3 ,not able to understand what I am doing.

Do you know atleast any books on weblogic portal 10.3(atleast 10 or 9.2)
please share or shed some lite on this .

Thanks a lot
Viswa

Peter Laird said...

@viswa

I see what you mean. With BEA, we had a good set of documentation, all referenced from a single web page. I just went to the Oracle migrated docs, and don't see an obvious place to start. I *think* they migrated all of the BEA docs, so it may just be a matter of finding them. They may be over on metalink (pwd protected)?

For devs, my JSF whitepaper covers a lot of topics. But if you are brand new to WLP, it probably jumps in a little too deep.

If you have WLP installed, what I like to recommend are the cheat sheets. There are found in Eclipse like: Help->Cheat Sheets->WLP

Also, the WLP discussionn forum is a good place to ask questions.

As you can tell, I am no longer on top of WLP stuff. I changed jobs about 4 months back.

Peter