[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.

[unocelli]

No, if you enable it will be send all 3000 tags to the client, also tags that are not displayed in views.
Should only be enabled if you see that values are not being displayed or updated. it should mainly be disabled if you have a lot of tags. Try it

[henjoe]

No, if you enable it will be send all 3000 tags to the client, also tags that are not displayed in views. Should only be enabled if you see that values are not being displayed or updated. it should mainly be disabled if you have a lot of tags. Try it

I see, so this is how it behaves, now I know. So what is the use case for enabling it?

[unocelli]

@henjoe The management of tags to be sent to the client according to the active views is not simple. and therefore only needs to be reactivated to check when there are problems updating values.

[henjoe]

@henjoe The management of tags to be sent to the client according to the active views is not simple. and therefore only needs to be reactivated to check when there are problems updating values.

Supposed I have 5 clients on separate computer /mobiles. Each device viewing different views, should I enabled it or no? I really got confused when to enabled it.

And also, the 3000 tags I mentioned on my problem, it only has 1 client which is also the computer hosting the fuxa. So basically, it doesnt send any values to any clients on the network.

[unocelli]

@henjoe Then it would not be a good idea for a web application such as FUXA to disable it as standard so that it only supports one client 😉. The management is done differentially for each client (socket).
Please disable it and you will see that each client receives the values for the views it is displaying, if not there is a BUG