Enfocus Community

I have about 60 flows running on our server and it's getting more unstable over time. I need to restart once or twice a week or processing slows to a crawl. The VM is not powerful enough (Only running 12 GB of RAM and older processors), but it's a struggle to get more virtual resources from IT. Even with no jobs running through the system, processor is between 60-80% and memory is about 85% utilization.

I'd like to know if Switch needs to run on its own server, or if it would be possible to run it on a much more powerful server along side my MIS software. (That server has 256 GB Ram and 56 CPU cores.) Definitely more power available there, I just don't know if Switch is designed to run alone or if it can coexist well with another big app.

Either way, I'd like to get some tips on optimizing my flow design. Is it better to have more flows with less elements, or consolidate them into fewer more complex flows? A lot of my flows are 50+ elements now. Are there any guidelines on how complex a flow should get before splitting it up? Are there changes I can make to my preferences to help Switch stay a little more stable? I build SQL statements with multiple checks to create metadata and sort jobs in flows, but some of my older flows use multiple conditions in 'Condition with variables defined' instead. Is it better to use SQL statements or scripting to replace these multiple condition checks? Any other things to watch out for?

Any tips / tricks / guidance would be appreciated!

Make sure you have the minimum of 4 processors available for Switch.
It-guys don't know what we need multiple.

One of my customers got a virtual server with just 1 core from the It-guys.

Here's a quick overview of our setup and some of the practices I follow:

Server Specs:
OS: Windows Server 2020 (running as a VM with fast SSD storage)
Memory: 32 GB RAM
CPU: 8 virtual processors (Xeon Gold 6354 @ 3.0 GHz)

Flows:
We run approximately 150 flows with varying levels of complexity.

Maintenance:
The system is typically restarted monthly during the Windows Update service window.
Occasionally (about every other month), I also perform a manual restart when needed.

Priciples:
I try to minimize the number of Pitstop elements in flows (a bit ironic), as too many tend to "slow down" the flow.
I prefer using Fastlane for simpler tasks to keep things efficient.
I avoid relying on desktop applications (like Photoshop or Illustrator) within flows — instead, I use CLI-based tools when possible.
I try to limit the number of "polling" instances (e.g., “check every minute”) to reduce unnecessary load.
I use Flow Links to avoid duplicating logic across flows when I need to reuse parts of an existing setup.

It's got 4 virtual processors

intel Xeon CPU E5-2690 v4 @ 2.6ghz

@magnus

Thanks for input Magnus.

I used to restart about once a month but that also was typically for Windows Updates. I've added quite a bit to the workload in the past year or two and seem to have hit a ceiling.

I do have some Pitstop elements I can consolidate. I'll work on that.
I'll check out Fastlane, haven't seen that one before now.
Not using any desktop apps, all CLI.
I've already reduced the polling where I can.
Using Flow Links and have consolidated some duplicate processes. Still looking for more.

Any thoughts on running Switch on the same server as my MIS?

wkopp wrote: ↑Mon Jun 02, 2025 5:04 pm Any thoughts on running Switch on the same server as my MIS?

It sounds to me that you already doing what you can to keep your Switch server in good shape.

I would avoid running Switch on the same VM as your MIS. Maybe not from a technical point of view, but it can be quite limiting, especially when you need to restart one system without affecting the other. In the long run, this setup might turn out to be more costly.
Instead, I’d suggest making a case to management for a VM upgrade that's better suited to your needs. A great opportunity to do this is during a Switch upgrade, that way you can transition smoothly to a new system (using temporary emergency licenses or similar).

Thanks again Magnus. Much appreciated.