Note: Due to heavy load, the latest workflow operation has been queued. It will attempt to resume at a later time

Question

Dear all,
sorry for opening another thread on this.
I think I have a performance issue with workflows attached to document sets in SharePoint. And I say “I think” because people keep telling me that this is the way it just is.
The user creates a new document set, which triggers a workflow in which the user has to confirm/review/approve a series of tasks. The time it takes from clicking the OK button on those task form to the workflow status moving to the next step is about 4 seconds.
And visiting that status page within those 4 seconds brings up the infamous “Note: Due to heavy load, the latest workflow operation has been queued. It will attempt to resume at a later time.” message.
Hitting Refresh in the browser after those 4 seconds will make the new workflow status appear and the red text go away.
Is that normal? Is that the performance that everyone else is seeing as well?
I struggle to see why simply moving a workflow from one task to another should take that on a machine that isn’t doing anything else at the time.
(1)   
I have a standalone (non-clustered) SharePoint box, 4 CPUs, 8 GB of memory, more than half of that available, acting as application server and wfe; only the database is on different box.
(2)   
The CPU only goes up to 18 or 19%, so CPU does not seem to be the bottleneck. Half the RAM is also still free.
(3)   
The workflow is designed with Nintex, and has about 9 flexi and review tasks – the last 2 of them in a loop iterating over typically 3 or 4 items.
(4)   
Looking at the logs it looks like the processing in Nintex only takes about 1 second – I don’t know where the other 3 seconds are going.
(5)   
There is nothing obvious in the logs.
(6)   
We’ve looked at all the “theoretical” improvements around throttling and batch sizes etc. – none of them appeared make any difference. And the workflow is so small that it looks like my tasks gets executed straight away. The problem appears
to be that the execution takes too long(?) and therefore has not finished by the time the page get redrawn.
(7)   
I am running perfmon and I can e.g. see one(!) workflow being loaded into memory – as expected as I am the only user.
(8)   
I am seeing a total of 3(?) SQL queries being executed(?). I get the Bytes Sent/sec spiking at 25K, and Bytes received at 18K. But is this good or bad or a bottleneck?
Where do I take it from here?
I have been told that “[…] most customers have no issue with this as they are used to the way SP operates and it can be slow at times.” Is it really that bad?
If it is worth watching more performance counters then I’d need to know what to compare them to.
Is there something else I am missing?
Thanks
Martin

Answer 1

Hi,
Before considering an additional hardware try to change following configurations for workflow:
Increase Throttle Size
Increase Batch Size
Time Out
Workflow Timer Interval
AutoCleanUpDays
Increase Throttle Size
The Workflow throttle setting controls how many Workflows can be processing at any one time on the entire server farm. By increasing the throttle it will allow the number of Workflows execution or can be initiated at a time.
Use below PowerShell command to get the current Throttle Size:
Get-SPFarmConfig | Select WorkflowPostponeThreshold
Use below PowerShell command to set new Throttle Size:
Set-SPFarmConfig -WorkflowPostponeThreshold 100
Increase Batch Size
This is the size that determines number of events processed for a single Workflow instance. Default value is 100, but it can be range from 1 to any number.
Use below PowerShell command to get the current Batch Size:
Get-SPFarmConfig | Select WorkflowBatchSize
Use below PowerShell command to set new Batch Size:
Set-SPFarmConfig -WorkflowBatchSize 200
Time Out
This decides the time out of the Workflow event. The default value is 5 and can be any integer. The time is in minute.
Use below STSADM command to get the current Time Out value:
stsadm -o getproperty -pn workflow-eventdelivery-timeout
Use below STSADM command to get the current Time Out value:
stsadm -o setproperty -pn workflow-eventdelivery-timeout -pv “15″
Workflow Timer Interval
This setting is applicable at Web Application level and not the farm level. 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.
Use below STSADM command to get the current Workflow Timer Interval value:
stsadm -o getproperty -pn job-workflow -url <Web Application Url>
Use below STSADM command to get the current Workflow Timer Interval value:
stsadm -o setproperty -pn job-workflow -pv “Every 10 minutes between 0 and 30″ -url <Web Application Url>
Here is the url for reference :
http://praveenkasireddy.wordpress.com/2013/06/14/workflow-due-to-heavy-load-the-latest-workflow-operation-has-been-queued-it-will-attempt-to-resume-at-a-later-time/