We have a workflow that has a conditional start which is working fine. However when the user makes a change then clicks Save the save window takes around 30 seconds to close. During that time we discovered the workflow is starting. How can we speed this up to where the user clicks saves then the windows close right after?
Solved! Go to Solution.
I've found this to be true in some situations as well. It appears the SharePoint forms are attempting to complete all events before closing or rebuilding the page. One event would be the Event Receiver that starts the workflow. In my case, I added a pause at the start of the workflow and that decreased the time.
In other cases, the time would be long on the first attempt to start the workflow, like first thing in the morning, then all other saves would be very quick.
A little explanation behind the two cases. The first case causes a speed up in the process because workflows attempt to start up and use available RAM in the web applications App Pool. So the workflow will run until it hits a pause in the workflow and at that time it is queued to be completed by the timer services or the workflow already completed. So by putting a pause at the start puts the workflow in a queued state right away. This quick feedback is given to the form and it closes.
In the second case, SharePoint caches the XAML files of workflows, the compiled version of them. It requires a use of the workflow to store the cache in the App Pool. It is common to have an App Pool reset over the night.
There are several other factors that would be harder to troubleshoot. But adding a pause could be a quick way to see what happens. The trouble is, a pause is not always warranted and causes an unnecessary delay in the process.
Thank you for the explanation. It was very through and detailed, i too was thinking of adding in the pause for 1 minute as a test. I appreciate you taking the time to explain this in depth.
I just wanted to add a few keywords for findability. The delay is caused by the workflow being started synchronously in the same IIS worker process (w3wp.exe). When you add a pause action in the beginning, the workflow instance only saves the data that's required for further processing in the content database and goes to sleep dehydrated, freeing up the thread and completing the request sooner. Afterward, when the time comes to wake up (the pause action's deadline passes), the instance gets rehydrated, and runs asynchronously in the timer process (owstimer.exe), maybe even on a different server within the farm.