The WebSphere Contrarian

Options for accelerating application deployment

Content series:

This content is part # of # in the series: The WebSphere Contrarian

Stay tuned for additional content in this series.

This content is part of the series:The WebSphere Contrarian

Stay tuned for additional content in this series.

In each column, The WebSphere Contrarian answers questions, provides guidance, and otherwise discusses fundamental topics related to the use of WebSphere products, often dispensing field-proven advice that contradicts prevailing wisdom.

A gift for you

It’s time for the holidays again, which means everyone is hurrying to finish up projects for the year, take care of shopping, and a variety of other traditional year-end tasks. All this activity likely means that you’d welcome any time saving tips, since you’re probably dealing with too much to do and too little time to get it all done. In doing my part to improve your efficiency, I’ll spend some time in this month’s column offering some tips for speeding up application deployment in IBM WebSphere Application Server, which will also apply to products such as IBM WebSphere Portal, IBM Process Server, and others that are based on WebSphere Application Server.

The application deployment flow

Before discussing some options on how to improve application deployment performance, it’s good to understand just what happens during application deployment. The processing can be broken down as follows:

  1. Connect from remote client to WebSphere Application Server via console or wsadmin.
  2. Copy of the application EAR from remote client to a temp directory on the administrative node (“WAS” application server for WebSphere Application Server “base” edition or the deployment manager for WebSphere Application Server Network Deployment).
  3. EAR is opened in read/write mode.
  4. Bindings are collected from deployer.
  5. Temp EAR is saved.
  6. Temp EAR is uploaded to application server node(s).
  7. EAR is expanded on application server node(s).
  8. Application server(s) are stopped and started.

If you look closely at the application deployment flow, you’ll notice that there are a couple of copy operations that occur. Copying a file, especially over a network, can be time consuming, so one of the first items to eliminate or minimize is the number of copy operations. This can be accomplished in a few ways:

  • Store the EAR file on the local file system for the administrative node, as opposed to the file system for the client node. Doing so saves a copy (#2 above) of the file from the node that the browser client or wsadmin client is connected to.
  • Distribute the binaries to all of the application nodes and expand the EARs using the WebSphere Application Server earexpander (you could also unzip, and so on), then deploy the applications using wsadmin AdminApp with the -nodistributeApp option; for example:

    AdminApp.install('<location of .ear>', '[ -installed.ear.destination /<somesharedlocation> -nodistributeApp –appname myApp …]')

    or uncheck the Distribute application option in the admin console when performing the install. Doing so saves yet another copy (#6 above) of the application, from the administrative node to the application server node(s), as well as the EAR expansion (#7).

  • Eliminate storing the application binaries in the WAS repository. A further optimization, that will eliminate storing the application EAR in the WebSphere Application Server repository — thus reducing the size of the repository — is to employ the zeroEarCopy option as shown here:

    AdminApp.install('/shared/myApp.ear', '[ -installed.ear.destination /shared –zeroEarCopy -nodistributeApp –appname myApp …]')

    Be aware that the zeroEarCopy option is only available using wsadmin, not in the adminconsole, and the fine grained application update, application edit, and application export options are not available when using zeroEarCopy.

By eliminating a couple of EAR file copies, as well as expansion of the EAR file, you will likely notice a significant improvement in application deployment time with both of these options. Further, by using the zeroEarCopy option the overhead associated with processing of repository by the deployment manager will be minimized, which will enhance deployment manager performance. This is because application binaries are typically comprise 80-90% of the configuration repository.

That said, I just know that there are some of you who will probably want to improve application installation performance even more. Before going into an option that enables parallel application deployment, I want to cover a few more time saving tips when using wsadmin:

  • Use RMI instead of SOAP (the default) for the wsadmin connection. The SOAP over HTTP protocol doesn’t have a built in request/response mechanism, and as a result there’s a (small) latency before a response flows back to a wsadmin client from the server. The RMI/IIOP protocol, on the other hand, does have a request/response mechanism so that equivalent requests using RMI/IIOP are served faster than those running over SOAP/HTTP.
  • Rather than running multiple wsadmin –c commands from a file or from the command line, use a single wsadmin –f command, with multiple commands inside the target file. For example, instead of :

    wsadmin -c "$AdminApp install c:\\myApps\\App1.ear {-appname myapp}"
    wsadmin -c "$AdminApp install c:\\myApps\\App1.ear {-appname yourapp)"

    create a file called my.jacl (or a jython file if you prefer) with these commands:

    "$AdminApp install c:\\myApps\\App1.ear {-appname myapp}"
    "$AdminApp install c:\\myApps\\App1.ear {-appname yourapp)"

    and invoke it with the simple command:

    wsadmin –f my.jacl

This is faster because only one process and JVM API are created for installation and the Java™ classes for the installation will load only once, as opposed to loading once each time you invoke a command either directly or by using the -c option.

Aside from the time-saving tips for wsadmin, there are also some space-saving tips you can employ that can translate into faster deployment times:

  • You can shrink EARs by putting large, rarely-changing third party JARs in shared libraries. If the shared libraries are NOT shared across EARs (you are just reducing what is deployed on each update), then the risks discussed in this article on J2EE packaging and common code are not an issue. If the JARs are shared across EARs you should probably think twice, again as discussed in this article.
  • You should also examine EARs for uneeded JARs -- or even worse: JARs that you SHOULDN'T include, such as jaas.jar, j2ee.jar, and jsse.jar since these are provided by Java and the runtime.

The need for speed

Maybe you’ve tried the suggestions above but still need to accelerate your application deployments further. There is another option involving writing a JMX program that uses the AppManagement Mbean, which enables you to run multiple instances of the JMX program in parallel.

A word of caution on this approach: As noted in the WebSphere Application Server Information Center, the API used is asynchronous so it returns immediately -- even if the install hasn’t completed; as a result, there’s a “sleep” method call in the example which might negate any speed-up that you might realize from running multiple programs in parallel!! As this was originally explained in the context of playing basketball, consider this is another example of Be quick, but don’t hurry.

How’s your memory?

Related to deploying multiple EAR files in parallel or running multiple application installations via scripting, keep in mind that each EAR file is going to create temporary objects in the administrative process JVM heap. The result is that garbage collection will need to be performed in order to reclaim space in the heap. Therefore, unless you enjoy diagnosing Out Of Memory errors, you’ll need to keep track of the total size of the EAR (or WAR) files for all jobs running at the same time, and make sure this doesn’t exceed more than 30-40% of the maximum heap size.

Hopefully, you can use some or all of the suggestions outlined here to speed up your WebSphere Application Server application installs, which in turn should enable you to spend more time on other more pressing matters, like holiday shopping. As always, your success is my reward. But just in case you're in the holiday spirit, I take a 42 long.


Thanks to Alex Polozoff and Keys Botzum for their comments and suggestions.

Downloadable resources

Related topics

Zone=Business process management, WebSphere
ArticleTitle=The WebSphere Contrarian: Options for accelerating application deployment