I have noticed that after either creating a new workflow, modifying and existing one, or running the workflow for the first time of the day it causes it to run slow for the first time. For example, I go into the workflow and make a modification and save/publish it. Then I go to my SharePoint list that kicks off the workflow. Instead of it running in an instant, it takes a few minutes. Is there a way to prevent that?
No, it's a feature. 
Sorry, but it really is. What SharePoint is doing for all workflows no matter how they are created is Caching them. So the first time they are run (first time after the nightly recycle of the app pool, first time after a publish) they will seem to run longer as SharePoint is caching the xoml file. The larger the file the longer it takes to cache.
The only ways to prevent it can be bad practices. Such as not recycling the app pool as often. Or running it for yourself once, which could erroneously send emails or change content that shouldn't be.
+11
Awww man! You have got to be kidding! I hate this because when I'm doing demos for customers I'm sitting there like an idiot while everyone is staring at me waiting for that first item to appear in the list. Ughhhh!
I do too. But here are some ways I went about it for a large solution I made for a client. They had a form the on submission started a workflow. It use to take over a minute for the form to close after submission for the first time. I had several options:
- Use a custom event receiver on the list to then start the workflow, this would be the optimal choice as it is run in another process and the form would just close and the workflow would start seemingly separately. I never noticed the "spinning up" time.
- Without code as an option, make a new workflow that starts on the list automatically as a one action workflow, to start another workflow, or pause, then start a workflow. Now the workflow that is started first and spun up is so small the caching time is at minimal and it will not be as noticeable to the user. The second workflow that would be started is the main workflow and would not be configured to start automatically.
- Put a pause as the first action. I think this helped and decreased the time, but it was very little. I think the best option if you do not code something is option 2.
+11
I would like to do #2 because code is not an option. However, that 2nd workflow would still be running for the 1st time making it still run slow. Correct? If not, what makes it faster since the shorter one is a separate workflow.
The difference is the user doesn't see it as much. A one action workflow will cache much faster than a 100 action workflow. The second starting workflow will still need to cache, but it will do so in the backend and would not be apparent to the user via a form closing time. That is your only advantage.
Workflows that need to cache will always take up the time they need, you can minimize this by breaking up workflows, but don't do it just because. Strategize it.
There are many activities a workflow performs(outside of caching) that will require it to run in the backend forcing it wait on the timer service that defaults to running every 5 minutes. So it is very common for workflows that have such actions/activities to not complete immediately.
+11
Thanks so much Andrew. This gives me a better understanding!
Reply
View our Community Site Map
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.