Throttle
The workflow throttle setting controls how many workflows can be processing at any one time on the entire server farm. This setting does not control how many workflows can be "In Progress" concurrently, but rather how many can be actively using the processor. When this number is exceeded, workflow instances that are started and events that wake up dehydrated workflows are queued for later processing. The default value is 15. This setting is per farm, so the number of front-end Web servers is irrelevant.
The impact of this setting is that when a workflow starts, the number of currently active workflows is checked. If it exceeds the throttle number, the workflow is not started and instead, a timer job is created to try running the workflow later. If the number of currently active workflows is less than the throttle setting, the workflow is started.
You can check the current throttle setting by running the following command:
You can change the throttle setting by running the following command, in which you can replace 25 with the new value:
The throttle property exists to allow you to control how many resources workflows require in your environment. Because you cannot designate dedicated "workflow servers" the way you can for index or query servers, this mechanism prevents workflows from overrunning your environment.
Batch Size
The batch size property can be secondary to the throttle property. This fact applies only in Scenario 1 (discussed earlier), where we are dealing with initial workflow starts. If the throttle setting restricts a particular workflow instance from starting (because too many workflow instances are running), no work items for that instance are released, regardless of the batch size setting. In this case, the UI shows a status of "Starting" for the workflow instance. The workflow is run by the timer service when the throttle limit is no longer exceeded.
An important point regarding your throttle setting is that workflows that are being run by the timer service do not count against your throttle limit. From a performance perspective, then, the throttle prevents the W3WP process from being overloaded, and the batch size setting prevents the timer service from being overloaded. Working together, and in conjunction with the workflow timer interval and the workflow timeout (discussed later), these settings help to keep your environment running smoothly while still handling the work necessary for thousands of workflow instances.
You can check the current batch size setting by running the following command:
You can change the batch size setting by running the following command, in which you can replace 125 by the new value:
The impact of this setting is that when a workflow starts, the number of currently active workflows is checked. If it exceeds the throttle number, the workflow is not started and instead, a timer job is created to try running the workflow later. If the number of currently active workflows is less than the throttle setting, the workflow is started.
You can check the current throttle setting by running the following command:
stsadm -o getproperty -pn workflow-eventdelivery-throttleYou can change the throttle setting by running the following command, in which you can replace 25 with the new value:
stsadm -o setproperty -pn workflow-eventdelivery-throttle -pv "25"The throttle property exists to allow you to control how many resources workflows require in your environment. Because you cannot designate dedicated "workflow servers" the way you can for index or query servers, this mechanism prevents workflows from overrunning your environment.
Batch Size
The batch size property can be secondary to the throttle property. This fact applies only in Scenario 1 (discussed earlier), where we are dealing with initial workflow starts. If the throttle setting restricts a particular workflow instance from starting (because too many workflow instances are running), no work items for that instance are released, regardless of the batch size setting. In this case, the UI shows a status of "Starting" for the workflow instance. The workflow is run by the timer service when the throttle limit is no longer exceeded.
An important point regarding your throttle setting is that workflows that are being run by the timer service do not count against your throttle limit. From a performance perspective, then, the throttle prevents the W3WP process from being overloaded, and the batch size setting prevents the timer service from being overloaded. Working together, and in conjunction with the workflow timer interval and the workflow timeout (discussed later), these settings help to keep your environment running smoothly while still handling the work necessary for thousands of workflow instances.
You can check the current batch size setting by running the following command:
stsadm -o getproperty -pn workitem-eventdelivery-batchsizeYou can change the batch size setting by running the following command, in which you can replace 125 by the new value:
stsadm -o setproperty -pn workitem-eventdelivery-batchsize -pv "125"Timeouthe timeout setting specifies the amount of time (in minutes) in which a workflow timer job must complete before it is considered to have stopped responding and is forced to stop processing. Jobs that time out are returned to the queue to be reprocessed later.The default timeout period is five minutes, which should be sufficient for most environments. However, if your workflows require more time to start, complete tasks, or modify other workflows (especially when running under load), you must increase this property value. Understand, though, that if a workflow instance encounters a problem that causes it to wait for a response (from an external system, for example) before the first commit point, you could encounter throttle issues because that waiting workflow instance is still considered part of the count of your currently running workflows that the throttle property monitors. This condition could prevent other workflow instances from processing.
You can check the current timeout setting by running the following command:
stsadm -o getproperty -pn workflow-eventdelivery-timeout You can change the timeout setting by running the following command, in which you can replace 10 by the new value:
stsadm -o setproperty -pn workflow-eventdelivery-timeout -pv "10"
Workflow Timer Interval The workflow timer interval specifies how often the workflow SPTimer job fires to process pending workflow tasks. This interval also represents the granularity of delay timers within your workflow. If a timer is set to delay for one minute, but the interval timer fires only every five minutes, the workflow delays for five minutes, not one minute.
For performance considerations, if your workflow creates a lot of work items, you can use this setting, in conjunction with the batch size, to control the processing of those settings. For example, with a batch size of 100 (the default) and a timer interval of five minutes (the default), Windows SharePoint Services processes at most 100 work items every five minutes. If the batch of 100 work items for one workflow instance finishes processing in two seconds, your workflow instance is sitting idle for 4 minutes and 58 seconds. This may be acceptable; it may not. Decreasing this interval setting allows more batches to process by causing the timer to fire more often and request more work to do; but it also means that workflow processing consumes more server resources.
The minimum value for this setting is 1, which means that the timer will fire every minute.
You can check the current interval setting by running the following command, in which you replace the URL with a valid path to a SharePoint application:
stsadm -o getproperty -pn job-workflow -url http://myWssServer You can change the interval setting by running the following command, in which value is a valid SPTimer schedule string:
stsadm -o setproperty -pn job-workflow -pv value -url http://myWssServer
No comments:
Post a Comment