# What Are Best Practices for Advanced Gateway Performance? (Threads, DB Pooling,Tag Performance, etc.) **URL:** \ **Category:** Ignition\ **Tags:** perspective, ignition81, scripting\ **Created:** [September 15, 2025, 12:44pm UTC](https://forum.inductiveautomation.com/t/what-are-best-practices-for-advanced-gateway-performance-threads-db-pooling-tag-performance-etc/110625 "2025-09-15T12:44:59Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Noah\_Casey](https://avatars.discourse-cdn.com/v4/letter/n/e480ec/32.png) [@Noah\_Casey](https://forum.inductiveautomation.com/u/Noah_Casey)\ **Post date:** [September 15, 2025, 12:44pm UTC](https://forum.inductiveautomation.com/t/what-are-best-practices-for-advanced-gateway-performance-threads-db-pooling-tag-performance-etc/110625/1 "2025-09-15T12:44:59Z")
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: ```python 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](https://us1.discourse-cdn.com/inductiveautomation/original/3X/8/0/80d58651fe3212ea178ecee98436cb81fd81426d.png) Threads drop back down as well: it seems like the average is ~58-100 **Before Changes:** ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/f/4/f4fe55bd14b731067cd08908ec04275a5caf82f6.png) 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! ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [September 15, 2025, 4:31pm UTC](https://forum.inductiveautomation.com/t/what-are-best-practices-for-advanced-gateway-performance-threads-db-pooling-tag-performance-etc/110625/2 "2025-09-15T16:31:57Z")
> [@Noah\_Casey](#): > > Am I going in the right direction with these .conf additions. 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. > [@Noah\_Casey](#): > > Are threads directly related to CPU threads when I set my x\_threads property 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. > [@Noah\_Casey](#): > > Advanced runscript() tags (These scripts are optimized for maximum performance) Unless you mean these scripts run in a few milliseconds, without inducing **any** network traffic (OPC, DB, web API), I am skeptical. > [@Noah\_Casey](#): > > Query Tags 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. ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [September 15, 2025, 6:18pm UTC](https://forum.inductiveautomation.com/t/what-are-best-practices-for-advanced-gateway-performance-threads-db-pooling-tag-performance-etc/110625/3 "2025-09-15T18:18:31Z")
> [@Noah\_Casey](#): > > #1 Am I going in the right direction with these .conf additions. 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. > [@Noah\_Casey](#): > > #3 Any other advanced details or settings to help me further increase my gateway performance would be very helpful! 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. ---
**Author:** ![Noah\_Casey](https://avatars.discourse-cdn.com/v4/letter/n/e480ec/32.png) [@Noah\_Casey](https://forum.inductiveautomation.com/u/Noah_Casey)\ **Post date:** [September 16, 2025, 12:43pm UTC](https://forum.inductiveautomation.com/t/what-are-best-practices-for-advanced-gateway-performance-threads-db-pooling-tag-performance-etc/110625/4 "2025-09-16T12:43:40Z")
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. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [September 16, 2025, 2:10pm UTC](https://forum.inductiveautomation.com/t/what-are-best-practices-for-advanced-gateway-performance-threads-db-pooling-tag-performance-etc/110625/5 "2025-09-16T14:10:15Z")
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.