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 ( http://technet.microsoft.com/en-us/library/cc287939.aspx ).


Ø  Programmatically by modifying  SPWebService.WorkflowEventDeliveryThrottle (cf  http://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 http://msdn.microsoft.com/en-us/library/dd441390.aspx 


 

Comments (1)
  1. zenicanin says:

    Thanks for the article.  Do you know how to set only one simultaneous workflow for just one site?  I don’t want to change global preferences…

    I have a list that uses a workflow to generate a custom autonumber, but if 2 people create a new item at the same time, the autonumber is the same.  So I basically need to somehow only allow 1 workflow at any given time…

    Any clues? Thanks!

Comments are closed.

Skip to main content