We implemented Try-Catch for a Web login page that requires some additional WF Executor steps.
The issue we found is that processing is being delayed about 30 seconds before marking the Catch step as executed.
Is this normal behavior or should we look at some WF we developed?
Before the existence of Try-Catch logic, login was like a breeze.
Try-Catch relieves many of the error processing hurdles but is this the tradeoff we should expect?
Thanks for any imput
1 Like
Dear @AE_Knights - Could you please answer about this interesting issue?
Hi! Willem,
When you use Try-Catch steps the workflow may be a little slow as it checks the conditions for each step.
1 Like
We experienced, that if more steps are involved, longer it will take to move forward.
If more processing power is applied, will this improve?
Try-Catch very useful for faster implementation but performance wise, capture error on each step and manage it accordingly.
2 Likes
Follow up on Try/Catch.
First of all, Try/Catch is very useful to speed up creating WF but have the issue that it WILL extend processing time quite a bit.
We have a WF that last about 30 seconds in execution time and 90 minutes processing the Catch step to process one row. The WF has just 61 steps and 16 are before and after the Try/Catch statements.
Inside the T/C steps, have 3 calls to WF that return status info, 6 filter steps and 1 switch. Rest are sequential Input/Output/Data Processing steps.
Incoming stream for Catch has about 29 fields and kept all in order from start to finish. very few renaming/deletion/meta steps, just to avoid duplicates after WF execution steps.
Throughout the WF, there are 4 streams that going to Catch step.
Where should we be looking to speed up the processing of Catch step.
Any other suggestions?
Hi Willem,
Would it be possible to share the workflow? It is difficult to understand the issue without taking a look at the actual workflow.
Thanks,
Anjana
Hi Anjana, I understand.
Tried to describe the WF.
Attached the WF that are involved in this case.
It is part of a larger process which I cannot pass entirely as it involves login information and the other parts do not last more then 20 seconds before Extracto_Mibanco starts.
Also wanted to mention that CPU does not spike when processing Catch Step and Intel i7 with 32Gb memory and SSD drive. These variables are not influencing execution time.
We have 19 similar processes and at this rate, when all could be finalized in 20 minutes effective execution, it takes 3+ times longer just for catch processing.
Hope you can provide some insights to improve execution times.
Regards.
WF_Extracto_Mibanco.psw (236 KB)
WF_ChequeaSiLlegoArchivo.psw (37.4 KB)
WF_CSV-TXT_con_timing.psw (19.6 KB)
WF_Gestion_Fechas.psw (92.6 KB)
WF_PDF_Print_Save_AutoIt.psw (93 KB)
Hello @wllmdjngh !
Suggestion in your workflows:
- Data Movement should be copy.
Ex steps: SC_TipoCuenta, WF_GestionFechas, WC_Movimientos
Look for similar steps. - Remove disabled steps to avoid confusion and better readability.
================================================================
Explanation of catch process in short:
Let’s say before catch step there are 4 steps. One step is Try itself. So we have to focus on 3 steps.
Try->S1->S2->S3-Catch
Catch step’s state will not go in finished state unless all the 3 steps (S1, S2, S3) are in finished state.
Over here catch step is not performing any operation but waiting for the 3 steps to finish.
So, we think that, in your case, there are some steps still in processing mode and catch is waiting for them to finish. Thus, it may look like catch is processing something.
================================================================
You can try below scenario to get better understanding of actual time taken for execution.
How much time it taking without using try-catch to execute your complete workflow i.e. by adding error hop wherever required?
2 Likes
Hi @pranav.sharma
Thanks for the input.
Regarding the S1-S3 steps, it is after all steps have finalized, with the green checkmark at each step, when executing Catch, every 10 seconds sends a stay alive and sometimes can last up to 2 minutes, 12 stay alive messages.
When time is of essence, for example, with the WF we are building, 2 minutes can close access to the web site we are trying to capture information for each account. After 2 minutes, it cuts me off and would have to start all over again.
Sometimes, saving such a WF can take a few seconds and other times, while working on PS, it does not display the stream data.
Changed the Programming and instead of using Rename step to decide which fields needed to keep, configured, which field were not needed(remove). This is maybe a better way to show the fields in the stream and also saving would speed up.
But still the WF is slow.
Hi @pranav.sharma .
I understand, if steps between the Try/Catch still are processing, it has to wait. But all plugins, when reaching Catch, are marked with green checkmark within 5 seconds.
And while processing the catch statement, the non-error route will continue its execution.
I just tried with a WF that was implemented with Try/Catch.
Using these plugins, it takes more than 12 minutes to execute.
Taking them out, it took just under 2 minutes.
It cycled 3 times through the same WF. So about 4 minutes per cycle when using Try/Catch. 2 times more executing without Try/Catch and the 3 cycles.
When removing the Try/Catch, it took about 15 minutes to save the WF. Normally about 10-15 seconds.
I would like to know additional tips to avoid this extended processing times. Have tried reducing variables in the stream, instead of plugins use javascripting.
WF use many WEB GUI, now legacy, plugins. Do not know if that delays processing.
Regards.
