Activity Concurrency Limit

Activity concurrency limit defines the feature to control the number of Activity Instances* or Activity Type which can run in parallel. Two tables are added to Farms database for this configuration. It is mandatory to restart the engine for these configuration changes to take effect.

SKActivityTypeConcurrency table: The columns available in the table are Application, ActivityType and Concurrency Limit. Two levels of concurrency can be set using this configuration.

• Application and Activity Type level: You can control the number of activity types which will run in parallel at the same time for a repository for a step type.
  Example: Within an application there can be only 10 script activity which will run in parallel.

• Activity Type level: You can control the number of activity types which will run in parallel at the same time.
  Example: Across all repositories there can be only 10 script activity which will run in parallel.

SKActivityNameConcurrency table: The columns available in the table are Application, Workflow, ActivityName, and ConcurrencyLimit. One level of concurrency can be set using this configuration.

Application, Workflow and ActivityName level: You can control the number of activity names (instances) which will run parallelly at the same time for a repository within a workflow.
Example: Within an application and workflow there can be only 10 MoveCopyFolder activity which will run in parallel.

The properties which can be configured in the farm database for Workflow Engine service is:

• maxruntimethreadsforconcurrentexecution: Number of threads which will be used to queue up the activities which timeouts the waiting periods to execute. The timeout activities will have Pending ('P') status for the activity in SWExecutionDetails table or BAM report.

• concurrentactivityexecutionwaittime: The wait time for an activity to start executing in synchronous mode. It is useful only when concurrency limits are set in farm configuration database for SKActivityTypeConcurrency or SKActivityNameConcurrency tables.

  <properties>
  <property key="loadbalanced"><![CDATA[False]]></property>
  <property key="loadbalanceserverport"><![CDATA[8853]]></property>
  <property key="loadbalanceclientport"><![CDATA[8859]]></property>
  <property key="port"><![CDATA[8855]]></property>
  <property key="maxenginethreads"><![CDATA[100]]></property>
  <property key="maxruntimethreadsforconcurrentexecution"><![CDATA[20]]></property>

  <property key="concurrentactivityexecutionwaittime"><![CDATA[15000]]></property>

  <property key="lastupdateddatetime"><![CDATA[]]></property>
  <property key="serviceexe"><![CDATA[WFEngine.NET2.exe]]></property>
  <property key="displayname"><![CDATA[Skelta - Workflow Engine]]></property>

  </properties>

   

  Note: Based on the type of workflows, load and scenario, it is advisable to configure these parameters during load testing to reach an optimum number and performance. Activity Instance* is a single step which is in executing/running stage. For example, there are 2 MoveCopy steps named MoveCopy1 and MoveCopy 2 placed in parallel with in a workflow. After the workflow is triggered, it would be one instance of MoveCopy1 activity and one instance of MoveCopy2 activity running at the same time. If the workflow is triggered twice it would be two instance of MoveCopy1 activity and two instance of MoveCopy2 activity running at the same time.