How many Processes can one VM support before I need another digital worker?

[kmcdowell]

I'm trying to determine the following:

1. How many automations can one DW support?
2. Can a DW execute simultaneously more than one automation process?

[david.l.morris · Accepted solution]

I am going to try answering this with a simple and an advanced answer. If you are new to Blue Prism or are evaluating it, I would say both answers below may be of interest, but the second answer will make almost no sense without experience with the terminology I'm referring to.

Before we get to the answers, let me define a few words. I think Digital Worker refers to a Runtime Resource, but frankly I'm fairly confident Blue Prism Marketing tosses this word around like it's a hacky sack. I personally do not use this term because it is only useful for generically talking about Blue Prism but quickly becomes useless when you get into technical questions which is what you're asking. Just to be clear, your question does make sense; I'm just explaining why I won't be using the term Digital Worker below. Keep in mind throughout this that I'm not referring to Remote Desktop Services. This is supposed to be technically possible, but I never actually finished implementing it the one time I attempted it. This allows using one machine for multiple connections to essentially have a bunch of desktops on the same machine. I'm just assuming you aren't referring to this. The standard approach is to have separate VMs. And any process/session running on that VM will see the same screen as any other concurrent process/session.

Blue Prism Process = A definition file of a sequence of actions that gets sent to the Runtime Resource to execute there and do the automation steps.

Session = A single instance of a Blue Prism Process running on a Runtime Resource

Machine = A Virtual Desktop or Physical Desktop running the Windows operating system (Windows 10/11 or even Windows Server).

Runtime Resource = A Windows process (Automate.exe) that runs on a machine and essentially hosts the running of any given Blue Prism Process. While not super common to do, you can run multiple Runtime Resource processes on a machine.

Simple answer: For question 1, there's no way for anyone to answer this for you unfortunately and it all comes down to math. How many hours does each automation need to run? If 1 hour each, then maybe 24 automations, but in reality things never work out that smoothly. For question 2, the basic answer is Yes more than one process can run on a Runtime Resource/Machine simultaneously. However, the best way to handle your setup to future proof and to avoid unexpected issues is to limit yourself to running a single Runtime Resource on any given Machine, and then also limit yourself to a single concurrent/simultaneous session on a given Runtime Resource. There are exceptions to this of course. Those exceptions are for utility automations that might run at the same time, but I personally would avoid doing this. What you REALLY want to avoid is more than one session of a process on the same Runtime Resource that both interact with the UI or use the Clipboard or anything else that could interfere with each other. So, for a basic approach, just go with a 1 to 1 approach and never run more than one automation on a given machine at the same time. See the Advanced answer for info if you want to do it anyway.

Advanced answer: For question 1, my answer is unchanged here. It's about math and about whether you do anything advanced. For question 2, for UI interaction automations, you basically shouldn't ever run more than one at a time on a given machine. They will interfere with each other. It is absolutely possible to design them to run at the same time and take turns interacting with the UI. In fact, I've done this with a dozen sessions at once before on the same machine/runtime resource, but it is not worth it and the design implications are ridiculous and you're just asking for issues. Some versions of Blue Prism do just fine for concurrent sessions on the same Runtime Resource. Some versions practically can't do this at all. Rather than discuss any specific versions, let me just say you should just proof things out to see whether what you want to do will work or not on any given BP version. There are two ways to accomplish running concurrent sessions. One is to run multiple sessions on the same Runtime Resource. This shares the memory limitations of a single process. Another way is to run each session on a separate Runtime Resource (all still on the same machine). I "believe" that this would mean each running session gets its own full pool of memory to use, but I am not 100% sure there as I've not tested those limitations. When you set up multiple runtime resources on the same machine, you use different port numbers, and that's how they are separated. In Control Room, it'll actually say {MachineName}:{PortNumber}. The issues I've run into with doing this is that you basically have to have stellar developers to accomplish this correctly. I guarantee you that you will lose your mind in the process of getting this working and then periodically when errors happen if you run multiple UI interaction automations at the same time. If you only run multiple "background" automations (ones that don't do UI stuff or use the clipboard etc.), then you may find success with this without too much difficulty.

I know my answer is excessive here, but I'm hoping you have some experts (maybe that is you, of course) who can dive into those paragraphs and parse out what that means for you.

What I want to avoid is some consultant telling you that this is a simple thing and that Blue Prism can do it no problem. Because this simply isn't true in practicality. I do believe if you ask Blue Prism themselves, they will tell you something like what I said except more diplomatically. They'll probably recommend you limit to one session per runtime resource and limit one runtime resource per machine, but they will also probably mention that it is technically possible to do more.

[kmcdowell]

This is AWESOME!!  😁 thx

[John__Carter]

To add to DM's answer, it's all down to whether the target apps/systems will allow multiple log ins and concurrent interaction. If that's possible, then you can think how to run parallel automations, as DM says - either as multiple sessions on one resource PC, or by multiple resource PCs on unique ports.

In practice I've only ever seen this work well with mainframes or entirely background/UI-less processes.