I am wondering how to know when to add more gateways.
Is there a rule of thumb?
Background
A department is wanting to have a vision client setup for a PLC HMI.
I am a little stressed because I already am pushing capabilities getting to good performance from many queries that look at faults over a couple years.
I was thinking maybe I could change them to use a C-More HMI.
They saw how easy the export and print works for Ignition Perspective pages I made though.
So now I am thinking maybe I should get them a separate gateway.
I am a little stressed because I already am pushing capabilities getting to good performance from many queries that look at faults over a couple years.
You currently have 1 Ignition gateway setup but you have I am assuming report queries that stress it out very much? This done via scripting or via the report module? I would recommend trying to fix the issue first because if its just a bad algorithm you implemented in scripting, another gateway won't do much good in terms of helping performance. But you need to be more specific about what the bottleneck you are experiencing is.
1 Like
No, I have really good queries with good indexes that people use regularly.
Ok what bottleneck are you experiencing then? Consistently high CPU loads? What makes you think it is too stressed what I am getting after.
1 Like
Desire for continued performance
I want to have my queries reach as far back as they can.
Right now, they reach back to 2 years and spit out paretos from all the faults over that time span in a reasonable time, even if I try to look at a department worth of machines at once.
Though, this is with just one client at a time I think.
Issues when many clients are run
Sometimes I can't look back so far.
Or sometimes there are multiple clients trying to use the pages, and the database seems to be slow.
Sometimes I get a clockdrift error if many clients are looking.
Bottleneck
Sometimes my database is the bottleneck, and sometimes my gateway cpu is I think.
I think it is driven by the number of clients open.
I don't get consistent high cpu load. I get spikes, 7am, 9am, 930am, or 415pm.
I think it is mainly when multiple clients are open.
Background
It took 5.082 seconds to complete the query from Jan 1st of 2021 to now for 12.5 machine (one machine is kind of split in half for outfeed).
Most my departments tables are looking at about 12 machines, pretty fortunately.
Though some things that I try to do, can't reach back 2 years.
One index per table by t_stamp, line, fault code.
I also use a join with a fault table to get the descriptions and sections.
I test many ways to construct the queries for speed.
I can tell when it is using the index and not.
I have been revising these queries to be very fast.
Sounds like you need a frontend/backend setup, where Reporting and all the Perspective clients are on the new frontend. A limited number of Vision Clients could still connect to the backend (Vision is a data retrieval load on the gateway, but not a data processing or UI scripting load).
1 Like
Is that using two gateways?
Yes, a frontend gateway for UI stuff, using remote tag providers, and a backend gateway for drivers and actual tag providers and any supervisory control event scripts, and the historian. For best results, the remote tag providers should point remote history at a read-only replica of the backend historian DB to avoid history breakage on heavy query load.
1 Like
I edited this a few times.
You already considered using Ignition Edge and two enterprise gateways is still better?
I started wondering about using Ignition Edge for my local HMI for some of the one-off machines.
It looks like I would need Edge Computing to script an export to an excel file, or I would have to get Edge Synch to send the data to my enterprise version of Ignition which could export to excel.
I was also thinking about a headless C-More HMI, but then I would have to write to an external memory because I don't think they can connect to both the plc via ethernet and a separate work network to write the data to.