We have recently upgraded our environment as part which we had to migrate from classic to modern folders. In old orchestrator we had 12 environments and now the same were created as folders in new orchestrator. we had around 2000 Assets and 200 queues which now were linked in all these folders.
All the new assets we are creating now in one folder and linking to all other so that we will have the flexibility to run a process in any folder.
My question is, will it have any performance impact on Robots?
Because we have been seeing few timeout issues with respect to queue items, exporting logs etc…
Thank you, but i have already gone through these links.
My question is not on the how part as we have already achieved that, i just want to know the performance impact of linking too many assets and queues to multiple folders.
Might be Yes, linking assets and queues across multiple folders can impact performance due to increased orchestration load, leading to delays and timeouts. To mitigate this, you can monitor Orchestrator resources, optimize the number of linked assets/queues, use dedicated assets for critical folders, and scale the infrastructure as needed.
Actually that’s the plan we have too, but till then we have to prevent the timeout issues.
Also updating an asset in one folder updates in all folders which means there is only one entry per asset in DB. Just wanted to check whether timeout is related to linking the resources or some other issue
You’re absolutely right - the issue could be related to high concurrent access to these shared resources across folders, increased load on the Orchestrator or database, or delays from logging and queue operations.
Monitoring infrastructure and optimizing access patterns can help reduce these timeouts.
Care when taking some responses to heart, at least 2 in this topic look like pure generic ChatGPT answers. They’re not wrong per se, but not really that helpful either.
When it comes to the question itself, when we moved from Classic to Modern, if I remember correctly we’ve also seen an increase in timeouts (also OnPrem in Azure), but we’ve had waaay less queue and asset linking (different setup architecture), so I’d lean more into the difference being a bit more related to just Classic vs Modern than to the number of links per se.
Let’s put things into perspective - 2000 assets * 12 environment links = 24.000 db entries. Unless you’re running your Orchestrator on a literal potato, no db will ever choke on something like that, and that’s where the main load will be (since from the Orchestrator perspective it’s the same API queries regardless in how many folders something is).
That said, the gpt generated answers are not wrong - check your IIS logs, Orchestrator host resource load, and DB load. If you’re spiking there, you might need to scale it up a notch.
Also - could be helpful if you’d state the versions you’ve upgraded from and to (especially the to version). There might be something that’s unoptimized that was later enhanced, for example.
Before coming to a conclusion about linking better to check the orchestrator load and also UiPath recommends using retry scope around get queue items or get assets in most cases as it has been observed frequently about connectivity for may reasons..so a simple retry can also fic the issues
We have cleared old data from DB and it helped to overcome the timeout issue.
However we could notice some lag in accessing Orchestrator, we are still checking whether its due to resource linking between folders. will post here once we get the confirmation.
Yeah, be careful with that one.
If the networking failure is on the wrong moment, it can (and will sooner or later) leave queue items InProgress that are effectively Abandoned (as the robot never got them). And on the Retry it will give you a new one (since it can’t dispense an InProgress item with the standard queue item get).
There’s not really a better solution though, but if you’re retrying on GetQueueItem, make sure to handle InProgress at some point (or make sure you’re ok with transactions going Abandoned).