By Softlanding
Share

Tuning SharePoint Workflow Engine

September 27, 2017

Tuning SharePoint Workflow Engine

Please read though the following articles then come back here:

Summary

In summary, SharePoint attempts to run Workflows synchronously under the w3wp process, when the number of workflows exceeds 15 per content database, they are converted to SPWorkItems and queued. This queue is then handled by the “job-workflow” Timer Job, which runs every 5 minutes by default. The “job-wofklow” Timer Job is ran by SharePoint Timer Service and only runs on Servers which have the “Microsoft SharePoint Foundation Workflow Timer Service” running.
Tuning

The configuration options are below:

  • Throttle
    • The number of workflows that can be processed concurrently per content database.
    • Default: 15
    • Change using: "Set-SPFarmConfig –WorkflowPostponeThreshold 20"
  • Batch Size
    • The number of SPWorkItems that the “job-workflow” Timer Job will attempt to complete in one run.
    • Default: 100
    • Change using: "Set-SPFarmConfig –WorkflowBatchSize 200"
  • Timeout
    • How long the job-workflow Timer Job has to complete its batch before it is forcibly shut down.
    • Default: 5 mins
    • Change using: "Set-SPFarmConfig –WorkflowEventDeliveryTimeout 20"
  • Workflow Timer Interval
    • How frequently the job-worflow Timer Job runs.
    • Default: 5 mins
    • Change using: "Set-SPTimerJob –Identity job-workflow -Schedule  "Every 2 minutes between 0 and 59""
  • Workflow Timer Instances
    •  How many servers run the “Microsoft SharePoint Foundation Workflow Timer Service”, this service run the “job-workflow” Timer Job.
    •  Default: Each Web Front End (Running on non WFEs requires extra configuration)
    •  Change using: Central Administration > Manage Service on Server
    • Note: This Service can only run on servers which also host the “Microsoft SharePoint Web Application Service” by default. In order for this service to run on Application servers you must create a script that calls UpdateWorkflowConfigurationSettings() on the SPWebApplication object, which will copy the Web.config settings from a front-end server. http://support.microsoft.com/kb/2674684?wa=wsignin1.0

Monitoring

Microsoft doesn’t provide any guidance around when the above options should be changed. Furthermore, they don’t provide any tools which show how taxed the Workflow Infrastructure is. The most common scenario would be that your users are complaining about workflows taking too long to start and/or complete.  

We have written a script which will show the count of each Workflow queue per content database. 
The script can be found HERE

The queue which we are mostly concerned with is the WorkItemHostType. The script will also show WorkflowTaskType, WorkflowFailover, WorkflowTimerType and WorkflowAutoCleanType queues.

Sample script output:
 Script Output

Tuning

Use the script above to monitor the WorkItemHostType count. If the count is constantly at 100, it means that the queue is very saturated. Start tuning by making sure that the Workflow Timer Service is running on all Web Front End Servers. Next, try increasing the Batch Size and monitor the outcome. If that doesn’t solve the issue, increasing the Throttle should help. However, note that this may cause some end user performance degradation as the w3wp worker processes will be processing more workflows. If all else fails, it may be time to add some more resources or servers to your farm.

If you have any questions please leave a comment.
Enjoy!

Loading Conversation