# Timer scripts are causing performance issue **URL:** \ **Category:** Ignition\ **Tags:** ignition81\ **Created:** [August 26, 2025, 5:59am UTC](https://forum.inductiveautomation.com/t/timer-scripts-are-causing-performance-issue/110166 "2025-08-26T05:59:06Z")\ **Posts on this page:** 14\ **Page:** 1
**Author:** ![Nageshwar\_Nagula](https://avatars.discourse-cdn.com/v4/letter/n/e9c0ed/32.png) [@Nageshwar\_Nagula](https://forum.inductiveautomation.com/u/Nageshwar_Nagula)\ **Post date:** [August 26, 2025, 5:59am UTC](https://forum.inductiveautomation.com/t/timer-scripts-are-causing-performance-issue/110166/1 "2025-08-26T05:59:06Z")
we have 3 dedicated, with fixed delay timer scripts in our project, which internally calls java gateway scripting module methods, one run at fixed delay of 1 sec and other two run at fixed delay of 10 sec, the 1 sec call pushes the data to DB and rest two timers queries the data and stores data to the tags. Also, some of the perspective screens calls the method call for viewing the reports Note: when we run those methods from outside ignition, they are completing in less than a minute. ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/f/2/f21c07c2aa49f808a4b4fe1d7596a90cdf9894bb.png) ---
**Author:** ![bkarabinchak.psi](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bkarabinchak.psi/32/83567_2.png) [@bkarabinchak.psi](https://forum.inductiveautomation.com/u/bkarabinchak.psi)\ **Post date:** [August 26, 2025, 11:38am UTC](https://forum.inductiveautomation.com/t/timer-scripts-are-causing-performance-issue/110166/2 "2025-08-26T11:38:03Z")
Would be helpful if you can share your script(s) so we can see if there is anything there that could be causing such behavior. ---
**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:** [August 26, 2025, 12:23pm UTC](https://forum.inductiveautomation.com/t/timer-scripts-are-causing-performance-issue/110166/3 "2025-08-26T12:23:39Z")
> [@Nageshwar\_Nagula](#): > > Note: when we run those methods from outside ignition, they are completing in less than a minute. This isn't actually helpful unless your outside test is using the same JDBC driver with the same connection properties. Share your SQL. Also note that a fixed delay timer setting for a task that takes 30 seconds will run every 40 seconds. ---
**Author:** ![Nageshwar\_Nagula](https://avatars.discourse-cdn.com/v4/letter/n/e9c0ed/32.png) [@Nageshwar\_Nagula](https://forum.inductiveautomation.com/u/Nageshwar_Nagula)\ **Post date:** [August 26, 2025, 12:36pm UTC](https://forum.inductiveautomation.com/t/timer-scripts-are-causing-performance-issue/110166/4 "2025-08-26T12:36:20Z")
> [@pturmel](#): > > This isn't actually helpful unless your outside test is using the same JDBC driver with the same connection properties. > > Share your SQL. > > Also note that a fixed delay timer setting for a task that takes 30 seconds will run every 40 seconds. the scripting module not using the ignition jdbc connection details, java scripting module has JDBC utils which is creating the connection for duckdb and that connection is used for the java methods. ---
**Author:** ![bkarabinchak.psi](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bkarabinchak.psi/32/83567_2.png) [@bkarabinchak.psi](https://forum.inductiveautomation.com/u/bkarabinchak.psi)\ **Post date:** [August 26, 2025, 12:40pm UTC](https://forum.inductiveautomation.com/t/timer-scripts-are-causing-performance-issue/110166/5 "2025-08-26T12:40:50Z")
Again I urge you to share your actual script especially since you are doing things that are not the standard (using a packaged JBDC like mysql/postgres/sql server) and leverage the system functions. ---
**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:** [August 26, 2025, 1:14pm UTC](https://forum.inductiveautomation.com/t/timer-scripts-are-causing-performance-issue/110166/6 "2025-08-26T13:14:50Z")
We aren't mind readers. We need to see your code in order to help you. What you've shared so far indicates that your title is wrong. In that your SQL is causing your performance issue. Share your code. If you cannot, you should be using IA support, or hire an integrator under an NDA. ---
**Author:** ![Nageshwar\_Nagula](https://avatars.discourse-cdn.com/v4/letter/n/e9c0ed/32.png) [@Nageshwar\_Nagula](https://forum.inductiveautomation.com/u/Nageshwar_Nagula)\ **Post date:** [August 26, 2025, 2:04pm UTC](https://forum.inductiveautomation.com/t/timer-scripts-are-causing-performance-issue/110166/7 "2025-08-26T14:04:27Z")
> [@pturmel](#): > > If you cannot, you should be using IA support, or hire an integrator under an NDA. I cannot share the script and SQL, probably we will go through support ticket. ---
**Author:** ![Steve\_Laubach](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/steve_laubach/32/60900_2.png) [@Steve\_Laubach](https://forum.inductiveautomation.com/u/Steve_Laubach)\ **Post date:** [August 26, 2025, 2:27pm UTC](https://forum.inductiveautomation.com/t/timer-scripts-are-causing-performance-issue/110166/8 "2025-08-26T14:27:10Z")
That’s the only way to fix this kind of an issue. This could be caused by a number of issues both on the script side and on the database side so it’s hard to help you without knowing what you’re doing. 1 minute seems like a long response time to me. Are you getting the same response time running your queries directly in your database? I’m not familiar with duckdb but a Google search told me it’s a high performance relational db. You may want to look at the execution plan that your query is getting and see if an index could speed that up a lot. You can query against millions of records in MSSQL in seconds so I feel like 1 min execute time is likely to be using a bad execution plan or a deadlock. You could be getting full table scans because of missing indexes or something along those lines. I don’t know with duckdb but with MSSQL you generally avoid these deadlocks by making queries set-based and avoiding anything that creates an SGAM lock. You can also add a SQL log file for each core on the db server to allow concurrent SGAM locks. If there’s something like that in duckdb then you want to look at what’s happening there. That said, you want to generally avoid SGAM locks like the plague on MSSQL; especially in systems with multiple clients calling the same queries concurrently. ---
**Author:** ![Nageshwar\_Nagula](https://avatars.discourse-cdn.com/v4/letter/n/e9c0ed/32.png) [@Nageshwar\_Nagula](https://forum.inductiveautomation.com/u/Nageshwar_Nagula)\ **Post date:** [August 26, 2025, 7:01pm UTC](https://forum.inductiveautomation.com/t/timer-scripts-are-causing-performance-issue/110166/9 "2025-08-26T19:01:05Z")
actually outside ignition these duckdb queries are taking approximately 2.5 sec through java ---
**Author:** ![ryan.white](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ryan.white/32/73193_2.png) [@ryan.white](https://forum.inductiveautomation.com/u/ryan.white)\ **Post date:** [August 26, 2025, 7:08pm UTC](https://forum.inductiveautomation.com/t/timer-scripts-are-causing-performance-issue/110166/10 "2025-08-26T19:08:32Z")
> [@Nageshwar\_Nagula](#): > > through java Do you mean in a standalone Java application? Or just running the query through some db management/querying tool? ---
**Author:** ![Steve\_Laubach](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/steve_laubach/32/60900_2.png) [@Steve\_Laubach](https://forum.inductiveautomation.com/u/Steve_Laubach)\ **Post date:** [August 26, 2025, 7:18pm UTC](https://forum.inductiveautomation.com/t/timer-scripts-are-causing-performance-issue/110166/11 "2025-08-26T19:18:55Z")
From rough overview… 2.5s is generally fine for query performance. If you see it sometimes executing basically instantly and other times taking a long time it’s likely a deadlock situation. You can probably test this by making a form with a bunch of bindings that are populating datasets using the same query. Simulate multiple clients pounding it simultaneously. Don’t do that when the production system is using the database (I’m assuming this is only select queries). The next step I would recommend is taking a copy of your script to a test page and calling it from a button using sample data. Isolate each part of the process to see where you’re getting into the chunky performance and figure out why they’re taking a lot of time. If you can’t make things perform faster; spin up a thread to execute them so the processing isn’t locking up your main thread. ---
**Author:** ![Nageshwar\_Nagula](https://avatars.discourse-cdn.com/v4/letter/n/e9c0ed/32.png) [@Nageshwar\_Nagula](https://forum.inductiveautomation.com/u/Nageshwar_Nagula)\ **Post date:** [August 26, 2025, 7:31pm UTC](https://forum.inductiveautomation.com/t/timer-scripts-are-causing-performance-issue/110166/12 "2025-08-26T19:31:49Z")
Standalone java application (Gateway Scripting Module) using main method testing the performance outside the ignition ---
**Author:** ![Steve\_Laubach](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/steve_laubach/32/60900_2.png) [@Steve\_Laubach](https://forum.inductiveautomation.com/u/Steve_Laubach)\ **Post date:** [August 26, 2025, 8:15pm UTC](https://forum.inductiveautomation.com/t/timer-scripts-are-causing-performance-issue/110166/13 "2025-08-26T20:15:26Z")
This might be a duckdb thing. > > > \### What happens? > > When running multiple queries in parallel against the same JD…BC connection, the JVM crashes > > \### To Reproduce > > \`\`\`java > try (Connection c = new DuckDBDriver().connect("jdbc:duckdb:duckdb-test", new Properties())) { > Runnable r = () -\> { > try (Statement s = c.createStatement(); > ResultSet rs = s.executeQuery("select 1")) { > while (rs.next()) > System.out.println(rs.getInt(1)); > } > catch (SQLException e) { > e.printStackTrace(); > } > }; > > ExecutorService executor = Executors.newWorkStealingPool(); > List\\> futures = new ArrayList\<\>(); > for (int i = 0; i \< 100; i++) { > futures.add(executor.submit(r)); > futures.add(executor.submit(r)); > } > > futures.forEach(f -\> { > try { > f.get(); > } > catch (InterruptedException | ExecutionException e) { > e.printStackTrace(); > } > }); > executor.awaitTermination(5, TimeUnit.SECONDS); > executor.shutdown(); > } > \`\`\` > > This results in: > > \`\`\` > 1 > 1 > 1 > 1 > 1 > 1 > 1 > 1 > 1 > 1 > 1 > 1 > 1 > 1 > 1 > 1 > 1 > 1 > 1 > 1 > \# > \# A fatal error has been detected by the Java Runtime Environment: > \# > \# EXCEPTION\_UNCAUGHT\_CXX\_EXCEPTION (0xe06d7363) at pc=0x00007ffd2f78fdec, pid=26032, tid=2712 > \# > \# JRE version: OpenJDK Runtime Environment Temurin-17.0.6+10 (17.0.6+10) (build 17.0.6+10) > \# Java VM: OpenJDK 64-Bit Server VM Temurin-17.0.6+10 (17.0.6+10, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64) > \# Problematic frame: > \# C \[KERNELBASE.dll+0x8fdec\] > \# > \# Core dump will be written. Default location: C:\\Users\\lukas\\jOOQ\\3.19\\workspace\\jOOQ-pro\\jOOQ-test-integration\\hs\_err\_pid26032.mdmp > \# > \# An error report file with more information is saved as: > \# C:\\Users\\lukas\\jOOQ\\3.19\\workspace\\jOOQ-pro\\jOOQ-test-integration\\hs\_err\_pid26032.log > \# > \# If you would like to submit a bug report, please visit: > \# https://github.com/adoptium/adoptium-support/issues > \# The crash happened outside the Java Virtual Machine in native code. > \# See problematic frame for where to report the bug. > \# > \`\`\` > > See also: > > \- > \[hs\_err\_pid26032.log\](https://github.com/duckdb/duckdb/files/11296153/hs\_err\_pid26032.log) > > If this can't be reproduced on your end, I'm happy to provide the mdmp file. It's just a bit big for github. > > \### OS: > > Microsoft Windows \[Version 10.0.22621.1555\] > > \### DuckDB Version: > > v0.7.1 > > \### DuckDB Client: > > JDBC > > \### Full Name: > > Lukas Eder > > \### Affiliation: > > Data Geekery / jOOQ > > \### Have you tried this on the latest \`master\` branch? > > \- \[X\] I agree > > \### Have you tried the steps to reproduce? Do they include all relevant data and configuration? Does the issue you report still appear there? > > \- \[X\] I agree What happens if you run just a single instance of your query from a button with all timer scripts that hit the db stopped (so one query on the connection)? What happens if you try to run several from the same connection using the JDBC thing you are testing your queries from? ---
**Author:** ![JordanCClark](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/jordancclark/32/83362_2.png) [@JordanCClark](https://forum.inductiveautomation.com/u/JordanCClark)\ **Post date:** [August 26, 2025, 8:17pm UTC](https://forum.inductiveautomation.com/t/timer-scripts-are-causing-performance-issue/110166/14 "2025-08-26T20:17:34Z")
Have you tried compiling the JDBC driver separately and installing it to the gateway?