of the
Workflow wait conditions can be very useful. Say you need to have an email go to a customer 30 days prior to their contract renewal, it can be tempting to use a wait condition. However, excessive use of wait conditions has a downside.
- Performance: each waiting workflow instance carries performance overhead. The more waiting workflow instances that you have, the more server resources will be consumed by the Asynchronous Processing Service.
- If you change the logic in your workflow and republish (like update the text of the email sent to your client), it does not change waiting workflow instances. For example, if you change the renewal email frequency to 15 days rather than 30 days, any workflow instances that are waiting will not be updated. (See tip # 24 for a potential way to minimize this risk).
As an alternative to wait conditions, use a scheduled batch process using Scribe or SSIS with Kingswaysoft to fill the role of the wait condition. This can be scheduled to run in batch with no impact to performance of the Asynchronous Processing Service.
[…] yesterday’s tip we suggested to avoid wait conditions altogether; but if you must use […]
[…] yesterday’s tip we suggested to avoid wait conditions altogether; but if you must use […]
Can you tell me exactly what “resources” a waiting workflow uses? CPU? Memory? Or is it just a row in a database table. The reason I’m asking is, our async process keeps ramping up to use 36 gigs of memory and crashing our server. I’m pretty sure we have a badly-coded plugin going into some kind of infinite loop. But I just wanted to eliminate the possibility that some of these waiting workflows (only a few) are actually using memory.
Waiting workflow does not use a lot of the resources, it’s very efficient. As far as I know, it does not use CPU, and memory and database overheads are small. However small they are, if you have lots of them, overhead of managing conditions and waits will put some strain on the server. Imagine if you have a waiting workflow for every customer to send them a happy birthday email. Not a big deal, dormant 364 out of 365 days. But if you have 3 million customer records in your CRM, that’s 3 million waiting conditions to manage and that managing part will consume resources on your server.
Having said that, 36 gigs does not sound right and you are correct to suspect some rogue code.