Hi!
Just trying to learn a bit more from Ignition.
I wanna know how much cost does reading a tag have. With this I mean how much could impact a recurrent script reading a bunch of tags.
We have a project that is a bit overloaded and I'm trying to see where is coming from.
I know that is not the tags, but don't have any proof.
Any type of information on how reading a tag works would be nice.
Really just wanna learn more about how Ignition does things.
Thx!
How are you determining it's overloaded? If you're taking to an Allen Bradley PLC, take a look at your device statistics. If it's showing any overload (above 0%) consistently, then it's most likely one or more problems with the data structure in the PLC. How fast are you reading tags in the PLC? Are you using PlantPAx?
If the server or clients are bogged down, are you using bindings efficiently? Are you avoiding the use of the tag expression? Are you trying to do scripted reads from clients constantly (or even from the gateway)?
If you give us a little more details on what issue you're having or seeing and what you think the problem might be, we can help give better advice and guidance of where to look.
Agree with above, but need to know specifically which PLC and which driver, and what statistic are you using to determine overload?
Reading tags from a script is very lightweight. It just grabs the most recent value the tag has received from its source. Scripted tag reading in gateway scope does not cause any communications to occur, and does not cause any leasing to change.
(In Vision, there's the network callout from client to gateway that matters.)
When I meant overload I mean the Ignition Gateway, not actually the tag reading, srry for the missunderstunding. Even the answers help me to know where to look.
Thx!
What do you mean with this? I'm not really sure what do you mean with "leasing".
What/where are you seeing overload?
There is many different factors in overloading a gateway. Could be memory, CPU, VM configuration, database issues, or really bad code.
We have a 40%-60% in CPU.
We have about 70 perspective views working at the same time.
But it's a combination of bad code and bad design of perspective views. All of that with not the best DB connection...
So each and every Perspective view runs on the gateway.
It is possible that you are just asking too much out of your gateway.
Is the gateway running on a VM? Can you dedicate more CPU resources to the machine?
Do you have transforms etc... on those views?
If you know you have bad code and bad design on the Views, I would start with the easy low hanging fruit and start chipping away. Transforms that can be optimized etc... Post up some examples, if you can, and someone might chime in on some help.
Do you mean Perspective users/client sessions? Perhaps you should read the Ignition sizing guide and this addenda:
The gateway is running on it's own dedicated server. The database is running on another dedicated server. We are planning on upgrading it's resourced (well, talking with the client about that) because we are doing an expansion on some views that they need.
We also wanna do a remake of some views that we know they are consuming more than what they need.
Probably in the next months I'm gonna ask about some help.
What are the resources available to Ignition and the OS? Ie CPU cores and RAM, how much ram is allocated to Ignition in the ignition conf?
First and foremost, any script reading a bunch of tags should be reading them all at once with a single system.tag.readBlocking call. So my first question would be are the scripts actually doing that or is every tag being read individually?
Look into "Scale-out architecture". Sometimes your visualization load can substantially tax your gateway. You can scale out the visualization so the backend processing load is separate from the visualization load. I'd imagine 70 clients could get to the point where you start to see problems but it really depends on what your app is doing. You can have CPU load issues with far fewer clients if you are doing a lot of beefy processes.
We are reading all tags at once. We don't read tags individually with the exception when in a script we only need 1 tag.