When a SharePoint workflow is published for the first time or a new version is published, the first user to access the process may experience a slightly longer than normal response time the first time that the workflow runs.
I’m not sure of the exact details, but it appears to be something along the lines of the “JIT hit” that can be experienced in ASP.Net sites when a new/revised page is deployed.
In that scenario, the first user is “penalized” by the need for the page code-behind to be just-in-time (JIT) compiled, once this completes, response time is reduced.
I don’t know that SharePoint workflows get compiled into MSIL specifically, but apparently there is still some “background processes” that have to run once to incorporate changes to the workflow.
This is not to be confused with queued workflow processing, which can occur in cases of high server workload. These can commonly be seen when testing workflows that have wait periods, especially short ones like 5 minutes. It is common for these to be delayed for 5-15 minutes at least, which can make client side debugging a challenge. If possible, try to avoid debugging during “prime time” or during scheduled maintenance periods.
Filed under: Workflow Tagged: Delay, SharePoint, Workflow
