Not sure if this question goes here or in the customization forum. Apologies if the other, but I think this is a system issue not a coding issue.

We have pretty heavily customized approval workflow that we deploy via a WSP as a reusable workflow. The workflow is started by a JavaScript call to /_vti_bin/Workflow.asmx via the SPServices Codeplex project. The first time the workflow is executed after an app pool recycle it takes a while to start. In our test environments its around 30-45 seconds or so. After the initial warmup of the workflow all subsequent calls to execute the workflow take about 1 second to start. While this is annoying its workable. 

However, in production the initial warmup takes about 3 1/2 minutes (we timed this by starting the workflow directly from the Workflows ribbon control). This exceeds the HTTP timeout so the JavaScript call fails when SharePoint/IIS kills the thread and returns a "Request Timed Out" generic error page.

At first we thought maybe the issue was the workflow was taking a long time to initialize all the tasks so we added a step so the first thing the workflow does when it starts is go to sleep for 5 minutes. After the five minute pause the workflow actually starts the task assignment, item updates, etc. So the workflow should start right up then go to sleep for five minutes. This did not help, though.

My question is, how can I improve a workflow's warmup time? I saw the workflow-eventdelivery-throttle, workitem-eventdelivery-batchsize, and workflow-eventdelivery-timeout properties, but changing those values on my test boxes (which really don't have this issue) made no difference. Is there a setting somewhere that I can tell SharePoint to not uncache the XOML when the app pools recycle? Or some other similar knob to turn that will allow the first time the workflow is started to under 1 minute?

Hi lgoolsby,

We are currently looking into this issue and will give you an update as soon as possible.
Thank you for your understanding and support.

Thanks,
Daniel Yang
Forum Support
Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

Thanks Daniel.

Some additional info. I added an event receiver for the list and wired up a simple ItemUpdating handler to always start the workflow. I am not able to replicate the issue in this method. It seems the only time the latency happens is when using Workflows.asmx. This definitely looks to be an issue with the service, not with the workflow.

For reference, the event handler:

        /// <summary>
        /// An item was added.
        /// </summary>
        public override void ItemAdded(SPItemEventProperties properties)
        {
            base.ItemAdded(properties);

            SPWorkflowAssociationCollection workflows = properties.ListItem.ContentType.WorkflowAssociations;
            foreach (SPWorkflowAssociation workflowAssoc in workflows)
            {
                Guid workflowParent = new Guid("My Guid");
                if(workflowAssoc.BaseId == workflowParent)
                {
                    if (workflowAssoc.Enabled)
                    {
                        properties.Web.Site.WorkflowManager.StartWorkflow(properties.ListItem, workflowAssoc, string.Empty);
                    }
                }
            }
        }

You're looking at the warmup time for the webservice. That's going to take some hardcore performance analysis on the ASP.NET side of life. You should be looking at why it takes six times as long to fire on production hardware than test.

Things to check include the infamous CAPI2 errors, performance counters and to increase the logging in ULS to verbose to try to capture the execution. Beyond that you're looking at Procmon which is full on hardcore techie turf.

Your other option would be a warmup script of some sort.

• Edited by Alex BrassingtonMicrosoft community contributor Wednesday, February 18, 2015 11:45 PM

You're looking at the warmup time for the webservice. That's going to take some hardcore performance analysis on the ASP.NET side of life. You should be looking at why it takes six times as long to fire on production hardware than test.

Things to check include the infamous CAPI2 errors, performance counters and to increase the logging in ULS to verbose to try to capture the execution. Beyond that you're looking at Procmon which is full on hardcore techie turf.

Your other option would be a warmup script of some sort.

• Edited by Alex BrassingtonMicrosoft community contributor Wednesday, February 18, 2015 11:45 PM

You're looking at the warmup time for the webservice. That's going to take some hardcore performance analysis on the ASP.NET side of life. You should be looking at why it takes six times as long to fire on production hardware than test.

Things to check include the infamous CAPI2 errors, performance counters and to increase the logging in ULS to verbose to try to capture the execution. Beyond that you're looking at Procmon which is full on hardcore techie turf.

Your other option would be a warmup script of some sort.

At first I thought that, too, but you can see in the ULS logs when they are in verbose that the call to compile the XOML is made and then IIS throws a thread abort exception. Those two entries for that correlation ID ("compile started" "workflow could not be compiled, thread abort exception") are right next to each other with about 118 seconds between each entry. The issue is most definitely in the workflow compilation process when ran through the web services, but I don't think its directly related to the web service warming up. 

Hi lgoolsby,

You may have a try of this

  Right click on the AppPool and choose Advanced Settings
  Change the Idle Time-out (minutes) setting from 5 to 0.
  Change the Regular Time Interval (minutes) to 0 if necessary.
  Click OK
  Right click on the AppPool again and choose Recycle

After you recycle the IIS/ app pool, perhaps you can try to run a warm-up script as well, it may give a bit of help.

https://spbestwarmup.codeplex.com/

Thanks,
Daniel Yang
Forum Support
Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

All the settings you mention were already set to the suggested value.

I don't think a warmup script will help unless the warmup scripts actually kick off the workflow. In my JS code I make a call before starting the workflow to retrieve the workflow ID. This query returns very quickly, which implies the web service is already warmed up. Its only when we try to start the workflow that we run into issues. I should also mention that we are navigating to the site through the browser to get to the form to start the workflow.

Hi,

Thanks for the reply, if should warm-up script didnt help much.

If should this issue only happened in the first execution in a day after recycling, I suppose you can try to recomplile the workflow in the VS.

"To improve this performance, we can avoid using declarative workflows and can use Visual studio based pre compiled workflows to avoid any compilation time."

Thanks,

Daniel Yang

Forum Support

Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

Thanks for the input Daniel. I would like to avoid rewriting the workflow in VS if at all possible but will keep the idea in my back pocket.

Also just to mention it, i moved our workflow start code out of JavaScript and into an added/updated event handler and the workflow starts very quickly and is not subject to the HTTP timeout, or at least does not appear to be. I set the HTTP timeout to 10 seconds and even though the workflow takes ~1 minute to compile and start the first time on my VM the workflow does indeed start.

Hi lgoolsby,

It seems to be working for you when you use event handler, do you need any further assistance on this issue? Please let us know if you need.

Thanks,

Daniel Yang

Forum Support

Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.