[QUESTION] Maximizing Fuxa's Capacity: Seeking Insights on Tags, Hardware, and Concurrent Users

[mauroalexandre]

Hello!
We are currently in the requirements gathering phase and have encountered a question regarding the maximum capacity for tags and concurrent users that Fuxa can support.

Could you share your experiences regarding the largest project you've managed with Fuxa, specifically noting:

• The number of tags
• The hardware used
• The number of concurrent users

Your insights would be invaluable. Thank you!

[mauroalexandre]

In my case

Devices: 1
Tags: 477
Hardware: i3-12100, 8GB RAM, SSD 256
Concurrent users: 1

[MatthewReed303]

RPI CM4 64bit, running Fuxa, CodeSys, Node-Red, Databases etc currently 1000 Tags via OPC-UA, has VPN and reverse proxy and web clients including 2x onsite clients. The project will grow by another 1000+ tags next year when I upgrade next section of the plant and add large database and batching etc

Devices: 1
Tags: 1000+
Hardware: RPI CM4 64bit, 4GB Ram, 32GB EMMC, 128GB NVMe
Concurrent users: 2+

[robsori]

I tested consecutively, through simulations with the connection to a local OPC UA server (on the same PC):

Tags: 1024
Device: 1
Hardware: i3, 8 GB RAM, SSD 128
Connection: OPC UA
Concurrent users: 1

Tags: 2048
Device: 1
Hardware: i5, 8 GB RAM, SSD 256
Connection: OPC UA
Concurrent users: 1

Tags: 4096
Device: 1
Hardware: i5, 8 GB RAM, SSD 256
Connection: OPC UA
Concurrent users: 1

I noticed that the more the number of tags increases, the more difficult it is to configure the project. Increasing the hardware resources, the work becomes proportionally easier.
If you disable the connection, to stop reading the data, the configuration mode becomes easier even if there are many tags.

[hxjackcn]

I have used it in many actual projects. The connection is mainly OPCUA. The number of points is related to the refresh time. If it refreshes once a second, it will be too busy if it exceeds 3,000 points. This has always been a big problem because the number of points in my projects basically exceeds 10,000. At present, my practice is to deploy many fuxas to relieve pressure.

[robsori]

I have used it in many actual projects. The connection is mainly OPCUA. The number of points is related to the refresh time. If it refreshes once a second, it will be too busy if it exceeds 3,000 points. This has always been a big problem because the number of points in my projects basically exceeds 10,000. At present, my practice is to deploy many fuxas to relieve pressure.

I'm curious if you tried using a higher frequency CPU and if you noticed any improvements.

[martinjug]

Devices: 1
Tags: 100~150
Hardware: RPI 3B+ 4GB RAM 32GB SD CARD
Concurrent users: 1

Devices: 1
Tags: 100~150
Hardware: Windows 11 12GB RAM 256GB SSD
Concurrent users: 1

[hxjackcn]

I have used it in many actual projects. The connection is mainly OPCUA. The number of points is related to the refresh time. If it refreshes once a second, it will be too busy if it exceeds 3,000 points. This has always been a big problem because the number of points in my projects basically exceeds 10,000. At present, my practice is to deploy many fuxas to relieve pressure.

I'm curious if you tried using a higher frequency CPU and if you noticed any improvements.

Increasing memory and CPU has little effect. Node.js is single-threaded and has obvious defects. I use 32G memory and 8-core CPU, and the connection will be disconnected at 5000 points.

[Kiruthick-Roxx]

In My case:

Devices: 10
Read tags : 7000 (approx)
Registration enabled tags : 500
Database : InfluxDB
Connection : OPCUA
Concurrent users: 1
Hardware: i5-10400, 8GB RAM, SSD 500 GB
Polling Frequency : 200ms

With this configuration, it still works fine as I'm just having a single view with a single graph. I'm using it as DAQ server to collect and store to database

[FrancoTampieri]

In my case

Devices: 2
Tags: Fuxa server: 222 + Device 1: 127 + Device 2: 64 = 413
Hardware: N4200, 3.49GB RAM, SSD 64BG
Concurrent users: 1

I have 6 views, no graphs and no reports, all the device are modes tcp and polling are 500ms

[henjoe]

Device: 1
Device Type: OPCUA Client
Hardware: 16GB RAM Windows OS
Num of Tags: 3000 polled every seconds

Remarks:
When # Tags is around 1000 -1500, everything is smooth, when I added some tags around 3000, the UI for DeviceComponent starts lagging.

[henjoe]

Is your device Connections UI didnt Lag? I tried it at around 3000 tags (polled every 1s) and the UI is lagging.

In My case:

Devices: 10
Read tags : 7000 (approx)
Registration enabled tags : 500
Database : InfluxDB
Connection : OPCUA
Concurrent users: 1
Hardware: i5-10400, 8GB RAM, SSD 500 GB
Polling Frequency : 200ms

With this configuration, it still works fine as I'm just having a single view with a single graph. I'm using it as DAQ server to collect and store to database

[henjoe]

I have same experienced with you, when Tags is around 3000, the device connections UI gets lags now.

I have used it in many actual projects. The connection is mainly OPCUA. The number of points is related to the refresh time. If it refreshes once a second, it will be too busy if it exceeds 3,000 points. This has always been a big problem because the number of points in my projects basically exceeds 10,000. At present, my practice is to deploy many fuxas to relieve pressure.

[unocelli]

@henjoe have you disabled to broadcast to Client all Tags values?

[henjoe]

@henjoe have you disabled to broadcast to Client all Tags values?

To Be honest I always set this to Enabled.
If my understanding is right, this should be enabled when you have atleast 2 or more Web Clients right? Since my use case requires multiple users, thats why I always enabled this.