Recommended performance modifications for the Service Desk CA Workflow engine.


Article ID: 50701


Updated On:


CA IT Asset Manager CA Software Asset Manager (CA SAM) ASSET PORTFOLIO MGMT- SERVER SUPPORT AUTOMATION- SERVER CA Service Desk Manager - Unified Self Service KNOWLEDGE TOOLS CA Service Management - Asset Portfolio Management CA Service Management - Service Desk Manager



The following changes to the Service Desk configuration of the Service Desk CA Workflow engine will improve overall performance and help to eliminate minor resource related issues.

Please note that this document is intended to outline some basic improvements to the Workflow engines performance, and it should be noted that these settings can have compounding effects both good and bad. For example, increasing the tomcat memory and adjusting the xml files can greatly improve workflow performance, but this gain can be lost by over setting Enginepools.

Please use caution when making these changes.


  1. Make adjustments to the available Java memory for the workflow Tomcat engine.

    This will increase overall performance of workflow.

    These steps are for Windows, Linux and Unix environments:

    1. Open the NX_ROOT/NX.env file in a text editor.

    2. Locate the following variables in the NX.env file: -Xms64M -Xmx512M
      Change this to read: -Xms64M -Xmx1024M

    3. Make the same change to the .tpl file:

      On Windows: "NX_ROOT\pdmconf\NX.env_nt.tpl" file
      On Linux/Unix: "$NX_ROOT/pdmconf/NX.env.tpl" file

      This will prevent the change from being lost after running pdm_configure in the future.

    4. Recycle the Service Desk Daemon Service.

      Increasing the Max memory to '-Xmx1024' is sufficient for most clients, if there are enough resources this can be raised to 1536 which is the maximum amount of memory Tomcat can utilize in a 32 bit environment.

      If Workflow is installed on a Secondary server, please make the above change in the nx.env file on that secondary.

      Please see Technical document TEC491277 for more details.

  2. Make the following adjustments to the pm.xml and wl.xml files which will help workflow take advantage of the increase in available memory.

    1. Shut down Service Desk.

    2. Open /$NX_ROOT/bopcfg/www/CATALINA_BASE_WF/conf/Catalina/localhost/pm.xml in a text editor.

      1. At the top of the file, modify the line:

        <Context debug="10" docBase="C:/PROGRA~1/CA/SERVIC~1/site/Workflow/Server/dist/processmanager.war" path="/pm" reloadable="true">

        Change "true" to "false".

      2. Near the end of the file locate the line:

        <Environment name="ProcessEngineStackDepthLimit" override="true" type="java.lang.Integer" value="175"/>

        Change "175" to "500".

      3. Near the end of the file, locate the line containing the string:

        Resource auth="Container"

        Change maxActive from 100 to 200.
        Change maxWait from 1000 to 10000.

      4. Save and Close the pm.xml file.

    3. Open /$NX_ROOT/bopcfg/www/CATALINA_BASE_WF/conf/Catalina/localhost/wl.xml in a text editor.

      1. At the top of the file, modify the line:

        <Context debug="10" docBase="C:/PROGRA~1/CA/SERVIC~1/site/Workflow/Server/dist/processmanager.war" path="/pm" reloadable="true">

        Change reloadable="true"> to reloadable="false">

      2. Near the end of the file, locate the line containing:

        Resource auth="Container"

        Change maxActive from 100 to 200.
        Change maxWait from 1000 to 10000.

      3. Save and Close the wl.xml file.

    4. For the changes to the xml files to take effect, Tomcat must be allowed to redeploy the workflow using these new values. To accomplish this delete the contents of the following 2 folders:


      CAUTION: Do not make backup copies of the xml files or of the folders in the /CATALINA_BASE_WF/ directory structure as Tomcat will attempt to load information from the backups causing unusual behavior and possibly fatal errors.

  3. In the Workflow IDE adjusting the following settings can greatly improve performance or eliminate problems:

    1. Under Server Configuration on the Process Manager tab:

      1. EnginePools.

        The number of engine instances the server runs to process workflow activities.

        The default value is 50.

        This can be increased to allow more instances to run at any one time. The CA Support team recommends making small increases of 25, followed by load testing to determine the proper balance between resource usage and available engines to process workflow instances.

        CAUTION: Increasing this value can have a very heavy resource impact on the system overall and Support strongly recommends against going over 125 engine pools unless you have contacted support and this is done under their direction as other values for Tomcat will need to be modified as well. This is usually only necessary for a very specific error message which states that all engines are busy.

      2. MaxWorkitems

        This value is the maximum number of workitems the process engine keeps in memory. Once the number of instance workitems reaches this value, they are written to disk. If your CA Workflow server has extensive memory, increasing the MaxWorkitems value speeds up the performance of large iterations.

        Default value is 2500.

        Support recommends small incremental increases of 500 followed by testing and monitoring for impact as increasing this value will impact overall resource usage.

      3. WebServiceTimeout

        Indicates the amount of time that the web services actor waits for a response from a web service in seconds.

        Default value is 600 (10 Minutes)

        This generally does not need to be adjusted but in environments with extremely heavy web service activity increasing this to 900 (15 minutes) can give the instances a bit of additional time to complete.

      4. Timeout

        This setting affects two back-off times:

        1. If no process engine is available, timeout is the wait period before retrying;

        2. If a workitem cannot run because a process instance is suspended timeout is also the time before it is queued again.

          To tune the timeout to reduce re-queuing activity, increase timeout from its default value of 3000 ms.

          This value does not generally need to be adjusted but increasing it even slightly to 5000 can eliminate errors and incomplete instance runs.

    2. Under the Actor Tab, JavaScript actors, USD Initilizer:

      ActivityRetryCount = 5 // Number of times retry an activity before notifying an administrator
      MaxTimeToWait = 30 // The time in seconds to wait before retrying an activity

      Increasing these values can help eliminate problems where instances repeatedly get hung up waiting for additional information from Service Desk, or other processes.


Component: ARGIS