0

We are speaking of the time it takes for the workflow state machine to notice that task A is complete, thus satisfying a wait condition in a workflow definition, which then creates task B. User1 marks task A complete, & it takes between 2 & 20 minutes for task B to be created. Here is what I’ve learned:

The most common solution found on the forums is to cleanup the AsyncOperationBase table. It is said that performance will suffer if this table contains > 1 million rows, however, ours only contains 22K.

With CRM 2013, MS created a new type of workflow called “real time workflows”. These are the ones without the check next to “Run this workflow in the background”. We cannot use those because real time workflows cannot have wait conditions. In CRM 2011, it was usually just a few seconds before the state machine noticed a task complete & created the next one. It seems that with the introduction of real time, the other types are even further “in the background” … the most pertinent statement to this effect is from the URL below: “Background workflows are generally recommended because they allow the system to apply them as resources on the server are available. This helps smooth out the work the server has to do and help maintain the best performance for everyone using the system. The drawback is that actions defined by background workflows are not immediate. You can’t predict when they will be applied, but generally it will take a few minutes.”

Is there any possible solution using which the workflow process will help create task B in lesser time?

Arun Vinoth - MVP
  • 314
  • 1
  • 3
  • 15
user3599410
  • 1
  • 1

1 Answers1

0

What are the specifications of your Microsoft SQL Server, i.e. RAM, Disk, and CPU? How many Microsoft CRM Users do you have (both licensed and typical concurrent)? While not typically a factor in slow workflow performance, if the Microsoft CRM Server is underpowered, it could affect how fast the workflows are processed too. What are the hardware specifications of the Microsoft CRM Server (CPU, RAM)? It sounds like you may have a SQL Server performance problem, but the real way to identify that is through capturing some data and analyzing it. You should capture 5-15 minutes of data with the SQL Server PSS Perf Wait Stats trace tool available here - http://sqlnexus.codeplex.com/wikipage?title=Sql2005PerfStatsScript&referringTitle=Home and can analyze it with SQLNexus available at http://sqlnexus.codeplex.com/. Typically there are a few key missing indexes that if added to the Microsoft CRM database, will take care of most performance problems. Depending on the RAM on the SQL Server and if it is shared with Microsoft CRM and/or other services, you may need to consider either moving SQL Server to a dedicated machine and/or to upgrade the RAM or disk system on it for more optimal performance.

If you want to get more specific numbers and data from the workflows that have completed, you can get the actual processing time (CRM OnPremise only) using the SQL query below to run against your MSCRM database, i.e. Contoso_MSCRM (uncomment and enter in the name of your workflow if wishing to only see instances of your workflow that was mentioned above). Note that the time to process below is in minutes.:

SELECT Name, StartedOn, CompletedOn, DateDiff(mi,StartedOn,CompletedOn)as 'Time to Process', RetryCount,Message,ErrorCode,StateCode,StatusCode
FROM AsyncOperationBase WITH (NOLOCK)
WHERE OperationType = 10
AND CompletedOn IS NOT NULL
--AND Name = 'Name of Workflow'
ORDER BY [Time to Process] DESC

You do not have what I'd consider a lot of AsyncOperation records with ~ 22,000, but after getting some results with the query above, you can delete completed workflow jobs from the AsyncOperationBase table using the query in KB 968520, http://support.microsoft.com/kb/968520. Typically I set this up in a SQL job to run either on a nightly or on a weekly basis, so that it can be run during non-production hours.

Chad Rexin
  • 136
  • 4