I have an application where I have to take Web API data and write it to 100s of memory based tags.
Additionally, I may have to read 100s of those tags to compare values and do error checking.
The hardware running Ignition is beefy, already top of the line, so that cannot be improved.
Outside of the hardware considerations, are there any performance concerns with the following script functions (and their async varieties):
system.tag.readBlocking
system.tag.writeBlocking
What kind of read/write performance can I expect? Sub-millisecond? 1 ms? Keep in mind the tags are only memory tags, NOT connected to PLCs/hardware
Is there any way to get tag data into a script without using tag.read functions in order to streamline the process?
To be clear, I am not having performance issues yet and this is not in production, only trying to plan ahead.
Only 100s? Not 1000s?
How often are you wanting to read/write these tags?
You can always simulate and time how long it takes to read and write to 100s of memory tag values. Make sure you test it in the same scope you’ll be executing the real script in though. Ie running from a designer scope will be slower than executing it from the gateway scope. I doubt you’ll be 1ms rate, but I’d be expecting somewhere around the 100ms mark if not less. I could be wrong
Obviously make sure you’re bulk read/writing when calling the read/write functions as well. Don’t read/write to individual tags
A bit of an ambiguous scope right now, but technically could be 1000s depending on what the API provides.
Fair enough, definitely could run a test. Was hoping there was some kind of existing benchmarks or something.
You’ll just have to measure it yourself, and remember to consider the scope you run in. If e.g. you write to the tags from the script console you’ll be measuring the roundtrip to the gateway and back as well.
The single most important criteria is to minimize the total number of calls to readBlocking/writeBlocking by building substantial lists of tags to read or write in one go. Build lists with list comprehensions–they tend to be faster than loops using .append. If you must open code your list building loops, consider using java’s LinkedList implementation instead of jython’s list.
If the list or lists of tagpaths are constant, cache it/them in script module top level objects–don’t build them on every event.
You should be able to read hundreds of memory tags in single-digit milliseconds. Or faster.
Add some calls to java’s System.nanoTime() for fine-grained benchmarking.
@Kevin.Herron I will setup a test and make sure to run it in the gateway to mimic production
@pascal.fragnoud The API is third-party so I’m limited to what they’ll provide, but hopefully they’ll do the error checking we need. If not though, then I need my own solution
@pturmel Appreciate the input, fortunately everything can be configured to be static if needed. Will make use of nanoTime for the benchmark
What I meant is, you could do the error checking right after the API call, before writing to tags, instead of reading from tags to do the error checking as your first post suggested:
Of course this only works if you get all the data needed in one place.
The “error” checking is to ensure that the new values are different as they should always be changing, I need to detect stagnant values. Would either need to keep the tags in memory or read the value. Thinking about it now, could possibly be done using Tag on-change related scripts.
Regardless though, I will definitely need to do a fair bit of tag writing. This is uncharted territory for me with Ignition, so I need to be pre-emptive in the design choices.