Tuning webMethods Deployer and Deployment Productivity Improvement

webMethods 7 product suite comes with a better equipped Deployer compared to its earlier version. However the rich blend of functionalities comes at the cost of performance, especially if the enterprise is big and requires high frequency deployments. It is imperative to tune the deployment process and the product to meet the delivery SLAs and budget of the project. The following recommendations may help in improving the productivity of a deployment solution using webMethods Deployer:

Dependency Checking Options – A key functionality of webMethods Deployer is to check the inter-dependencies of the components being deployed. Dependency check can be set to (per deployment project) fully automatic, partially automatic or manual setting. The default setting is checking dependency always (fully automatic) which checks the dependencies every time the project is modified and through all the steps of deployment lifecycle. This mode of dependency check process is quite performance intensive and can slow down the system. Depending on the quantum of changes in the build system the dependency check option can be set to reduce (done only while build and deploy) or manual. This will give some performance boost to the Deployer server. Use ‘reduced’ and ‘manual’ for changes with moderate and minimal impacts respectively.

Source/Target Server Settings – Target and source integration servers are defined as remote server alias in the Deployer IS. While configuring the remote server alias the default keep-alive time is set to 0. This causes the Deployer to reconnect to the target continuously taking a performance hit. Change the default value to 10/20 (minutes) which reduces the frequency of the checks. Note, this setting can significantly improve the performance if there are several source/target servers configured.

Target Server Response – It was observed if the target server becomes unresponsive it can compromise the performance of the Deployer. In some cases the Deployer screens will fail to load. In the event of such an, the responsiveness of the target servers should be checked. If the target server is available but the request not getting completed try reloading the WmDeployerResource package in the target (for Integration Servers). If a single project is used to deploy packages in multiple target servers, the unavailability/unresponsiveness of a single target server can stop deployment to the rest. In this case the deployment can be continued by removing the faulty target server settings from the deployment map. If the screen does not respond, try editing the configuration files in WmDeployer package.

Use Clustered Deployment Approach – Instead of deploying to multiple nodes of a clustered environment separately use the clustered deployment approach where the deployment is done to primary node (IS, TN or PRT) and the primary node deploys to the secondary nodes. This saves valuable resources in the Deployer server.

Consider Automation – Most of the webMethods Deployer functionalities can be automated through services and out of the box scripts supplied with the product. The response time of the services and scripts are better than the user interface in that order. However some effort is required to write wrapper scripts/services to combine the Deployer scripts to achieve the process automation. If the enterprise is big and has an ongoing deployment requirement, investing some time and money to achieve the automation will prove to be productive in the long run.