What Are Best Practices for Advanced Gateway Performance? (Threads, DB Pooling,Tag Performance, etc.)

Ignition
, ,
1

Hello everyone,

I have recently been investing some issues in a few of our gateways and have learned above some additional configuration settings within the Ignition.conf file see below:

wrapper.java.additional.9=-Dignition.tags.expressionthreads=100
wrapper.java.additional.10=-Dignition.tags.scriptthreads=8
wrapper.java.additional.11=-Dignition.tags.scriptqueuemaxsize=20
wrapper.java.additional.12=-Dignition.tags.db_tag_threads=6
wrapper.java.additional.13=-Dignition.sqlbridge.maxthreads=5

I believe all the of the writing below is what each additional config value controls.

Tag Value Change Scripts:

wrapper.java.additional.1=-Dignition.tags.scriptthreads=5
wrapper.java.additional.2=-Dignition.tags.scriptqueuemaxsize=10

Expression:

wrapper.java.additional.1=-Dignition.tags.expressionthreads=10

SQL Transaction groups specifically:

wrapper.java.additional.1=-Dignition.sqlbridge.maxthreads=10

QueryTags:

wrapper.java.additional.1=-Dignition.tags.db_tag_threads=10

I have a few questions/clarifications:
After increasing all of these limits the first thing I had to do was increase the DB connection pool. I started the server and noticed that the DB kept faulting so I did an increase from 8 Max connections to 50 which is running very good now.

I’m assuming this is due to more scripts/expressions/other items executing at a faster rate therefore taking up active DB connections instead of waiting to execute.

This is my performance change:
After changes:

image
image1111×514 37.5 KB

Threads drop back down as well:
it seems like the average is ~58-100

Before Changes:

image
image1076×461 28.4 KB

I’ve also noticed that my tags/udts in the gateway browser now change instantly before the changes I would change a value/expression and it would take ~1 Minute + to set that value or execute the expression.

With all of this information I have a few questions:
#1 Am I going in the right direction with these .conf additions.

#2 Are threads directly related to CPU threads when I set my x_threads property if so why is my CPU performance still super low I want to make the most of my server and it seems like the CPU is not really being touched here.

#3 Any other advanced details or settings to help me further increase my gateway performance would be very helpful!

Additional details about this project specifically:

Full Perspective Project
We use many different UDTs that perform calculations such as:

  1. A Large amount of expression tags:
    1. Simple logic expression tags
    2. Advanced runscript() tags (These scripts are optimized for maximum performance)
  2. Reference Tags
  3. Memory Tags
  4. Query Tags
    1. A majority of query tags execute stored procedures rather than raw query statements.

All tags are setup with different tag groups with the fastest being 1 second and the slowest being around 30 minutes.

Any insights are greatly appreciated, thank you in advanced!

1 Like
2

No. That will reduce thread starvation incidents in these subsystems, but will not reduce the actual workload of your system. Patches a few pinholes in the stern of your ocean liner while an iceburg has ripped a huge gash in your bow.

No. Ignition is massively multithreaded anyways. The .conf settings are for applications with hundreds of thousands or millions of tags where the single-digit milliseconds rule doesn't suffice.

Unless you mean these scripts run in a few milliseconds, without inducing any network traffic (OPC, DB, web API), I am skeptical.

Yeah, no. Don't do this. Make a single timer or scheduled event that runs all of the necessary queries, one at a time, and writes the results to same-named memory tags.

Any tag valueChange events and/or runScript invocations that need to reach out to a DB or OPC or web API need to be moved to gateway events in the project.

2 Likes
3

Generally, no. These configuration knobs exist for a reason, but these are wildly different subsystems. The correct answer to "a performance problem" is to fix that one performance problem, not shotgun a variety of things and blindly hope they fix the (unspecified) issue. For one thing, even if you end up fixing an issue, you'll have no idea which thing you did fixed it.

Suffice it to say that there is no secret -DrunIgnitionFast=true parameter. The defaults are defaults for a reason, and it is much better to analyze a specific problem and derive a specific solution to that problem than cargo-cult what you can find here on the forums.

Your two performance graphs are not dramatically different, and neither really indicate a system I'd deem a pressing concern. As Phil said, application code errors are a much more likely root cause, which you have likely only band-aided over. There is no configuration parameter that can prevent a sufficiently motivated actor from crippling an Ignition gateway, guaranteed.

4 Likes
4

Thank you for the insights!

When working with data from any source (network traffic, databases, APIs, etc.), would you say the following is a good approach for architecting the flow?

  • Create reusable scripts in the Project Library and have them run on timers.
  • Once the data is retrieved, write the datasets into dataset memory tags.
  • Reference and use the data from those memory tags as needed within the project.

For scenarios where each event needs to be logged into a specific table (for example, recording state transitions):

If a tag changes from 0 –> 1, and you want to capture the duration of the previous state, would you recommend:

  • Using tag change scripts to calculate and log duration values,

  • Historizing the tag and using stored procedures (SPROCs) to calculate durations, or

  • Leveraging transaction groups for handling the logging automatically?

In your experience, which approach tends to be the most efficient and the least resource-intensive?

Thank you in advanced.

5

Yes, that's good. For durations, I recommend storing events with timestamps and computing durations when querying, using standard lead() or lag() DB functions in SQL.

1 Like