I have noticed that the execution time of some workflows does not match the execution times of the blocks in the logs. As you can see in the image, the workflow execution time is 84s, but the total execution time of all the blocks combined is approximately 55 seconds.
I have also checked the logs for any possible retries or errors in any of the blocks. Are there any possible solutions to reduce the execution time of the workflow? Also, what is the reason that the execution times do not matching at all?
Hi @YoggyAC7, there could be a few reasons why these might not be matching up. We've seen overhead equal to 2-3 seconds on complex workflows, but with a gap that large it seems likely that your workflow is waiting on something external to happen before it continues executing fully. The 84 seconds is from the startTrigger until the end of the very last block, so its possible that some of that time is spent idle. In this case it would be worth going through the logs and checking the start and end times of these block calls to see where that idle time exists.
Some other ways to reduce execution time, if you're not already doing them, include:
running blocks that dont rely on each other in parallel
using fewer blocks
consider batching loop runs instead of running sequentially (looks like you are already doing that in sendEmailBatches)
connection pooling or persistent connections with DBs to avoid cold-starting
HI @Mike_M. I have tried the things you suggested. I even tried running a workflow with just one block and a simple query, and there's still time discrepancy between the execution times. Is there are any setting for workflows that might be causing this?
What I meant to say earlier is that for any workflow you can expect some overhead, and 1-2 seconds is normal even for a small workflow. With more complex workflows it could add a few more seconds but definitely not proportionally.
Because its adding almost 30 seconds in the original workflow I'm wondering if those greyed out steps (returnResponse, sendExcludedUsersZBDUserId, and MMAlertwhentryingtosende...) are adding time that you don't see accounted for.
If you send me the workflow Id and/or a workflow Run Id for the original workflow thats running for 84s, I can take a look in our backend and see the time breakdown for myself and maybe add some clarity here.