About the “workflow-eventdelivery-throttle” parameter
The WorkflowEventDeliveryThrottle parameter is used to throttle the workflow events processing in WSS 3.0 / MOSS2007.
Understanding the Workflow Events processing
Where can a workflow event be processed? Events can be processed by either the worker process (W3WP.exe) or in SPTimerv3 (OWSTimer.exe).
To prevent web front ends (w3wp) from getting overrun by running too many workflows instances, there is a throttle limit. If more events than the throttle are already being processed, the newer events are enqueued as work items – they will be picked up by OWSTimer.
You can figure out if you’re in this situation by increasing the diagnostic level for the category "Workflow Infrastructure" to Verbose. Then, you'll have to check up the ULS logs for entries like:
08/19/2008 16:06:29.87 w3wp.exe (0x16E8) 0x1C7C
Windows SharePoint Services Workflow Infrastructure 936r Verbose
RunWorkflow: No pending events - possibly targeted for async delivery: List:/Site/MyList Item:<myItemID>
You can also check the performance counters :
Ø Windows Workflow Foundation\Workflows Loaded
Ø Windows Workflow Foundation\Workflows Completed
for the processes W3WP and OWSTimer.
When is the throttle used?
The WorkflowEventDeliveryThrottle is used to decide where to process workflow events:
Ø Synchronously in W3WP
Or
Ø Asynchronously in OWSTimer
How to set the throttle?
The throttle can be changed either:
Ø Manually, by running “stsadm -o setproperty -propertyname workflow-eventdelivery-throttle” without the “–url” parameter ( https://technet.microsoft.com/en-us/library/cc287939.aspx ).
Ø Programmatically by modifying SPWebService.WorkflowEventDeliveryThrottle (cf https://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spwebservice.workfloweventdeliverythrottle.aspx ).
Which value to set in the throttle?
There is no definite answer to this question… The answer should be based upon your configuration, number of FrontEnd servers, load, requirements, etc…
Consider the following scenario:
Ø a workflow, associated to a list, is set to be run each time a document is created.
Ø the event processing consumes resources and therefore takes some time to accomplish
Ø many users are simultaneously creating documents/items
What could happen in this scenario? At first, the throttle value may be quickly reached. At this point, w3wp will not process any new workflow events, instead they will be queued and will wait to be run by OWSTimer. So far so good, but what if OWSTimer cannot process events as fast as they arrive? The number of throttled items will increase continuously… Eventually, we may end up in a vicious circle: all events are throttled, hence increasing the load on OWSTimer, hence preventing OWSTimer to handle all events, etc… Users will report that the workflows are very slow to process: “I completed my task, and I have to wait until tomorrow for the next step”, “processing only happens overnight”…
Of course, some factors will mitigate this:
Ø when users stop working (e.g. during the night), OWSTimer will dequeue the throttled events,
Ø you could add other servers to your farm to have more OWSTimer
Ø you could change the throttle value to process more events in the W3WP (providing your W3WPs can afford it)
On heavy loaded systems, you could perform the subquery below to compare with the throttle:
DECLARE
@Now datetime
SET
@Now = dbo.fn_RoundDateToNearestSecond(GETUTCDATE())
SELECT
COUNT(DISTINCT BatchId)
FROM
dbo
.ScheduledWorkItems WITH (NOLOCK)
WHERE
Type = 'BDEADF09-C265-11D0-BCED-00A0C90AB50F'
AND
DeliveryDate
<= @Now
AND
(InternalState & (1 | 16)) = (1 | 16)
The idea behind this query is to get an indication for the possible throttle values. If the value returned by query is superior to the throttle (15 by default), any new workflow event will not be processed immediately, instead it will be enqueued and will wait to be run by OWSTimer.
Thanks to Yvan Duhamel for his help in writing this post.
More Info
can be found at https://msdn.microsoft.com/en-us/library/dd441390.aspx