Best practices for high performance apps

This guide outlines best practices for designing high-performance Tulip applications that scale efficiently in production environments. Following these recommendations will help ensure your apps remain responsive and stable, even as your operation scales.

What is a high-frequency trigger?

A high-frequency trigger executes more often than every 5 seconds (faster than 0.2 Hz). Machine attribute events, device events, and timer triggers are the most common sources of high-frequency execution.

Tulip recommends that triggers execute no faster than 5 seconds (0.2 Hz) to maintain app performance and responsiveness.

Trigger queue impact

App triggers execute top-down in a sequential single-threaded queue, known as the trigger queue.

Two factors determine whether the queue operates efficiently:

1. Queue entry rate: How frequently trigger events are added to the queue
2. Queue exit rate: How quickly trigger logic completes execution

When triggers enter the queue faster than they exit, the queue builds up. Sustained trigger queue buildup causes app latency and, in some cases, dropped trigger events.

Think of trigger frequency like highway traffic. If too many cars enter the highway in a short time period, traffic slows down. To avoid buildup, cars must enter at a rate the highway can accommodate.

Combined frequency

The combined rate of all trigger events in an app determines overall queue entry rate. Each trigger event you configure adds to this combined rate.

See the table below for examples of combined frequency:

Trigger logic speed scale

The type of trigger logic determines how quickly triggers exit the queue. Logic that requires Cloud communication, Transitions, or external system responses take significantly longer to run than local operations.

The table below describes the speed of different types of logic.

Technical factors that impact trigger performance

• Local hardware - Trigger logic executes on local hardware, and thus device specifications critically impact how quickly triggers complete and exit the queue. For device specifications, see Recommended Devices for Tulip Player.
• External dependencies - External dependencies include connectivity to the cloud, local network latency, and the response time of external systems like Enterprise Resource Planning (ERP).
• Devices connected via Tulip Edge devices - Tulip apps are dependent on cloud connectivity, which can introduce latency. For example, a torque controller connected to an edge device still communicates with Tulip Player through Tulip cloud services. To understand device connections, see these sequence diagrams for device connections via Tulip drivers.
• Latency issues with Connector Functions - Slow response from a system (e.g. an ERP) via a connector function can cause app delays, especially if the app loops through many records with each requiring a potential two-second API call. To understand system connections, see these sequence diagrams for connecting to enterprise systems.
• Latency between shop floor and Tulip cloud infrastructure - To minimize latency, your Tulip instance is located in the same geography as your shop floor.

Guidance

Avoid high-frequency triggers

You should avoid high-frequency triggers where possible and instead use other features, such as Automations.

You may also want to redesign your application architecture to operate at a lower rate. For example:

• Less frequent data reporting with queries and aggregations
• For asynchronous use cases, looping can be performed via Automations
• For synchronous use cases, looping that must be done sequentially should be done via Functions

If you must use a high-frequency trigger, you should configure the trigger to only execute local work (e.g., updating an app variable). Then, use a low frequency trigger to do the slower executions (e.g., updating a table record).

If you are using a high-frequency Timer trigger to rapidly react to context outside of a Tulip app, you may be able to use an “Event Stream” Tulip Machine with machine and device triggers.

Usage of Tulip Table APIs

Using Table APIs to read or write multiple times per second can impact your instance’s performance and cause delays in reading or storing data. The recommendations below apply to all scripts and trigger actions that run Tulip APIs on a Tulip instance:

Recommendation

• Plan your logic execution to abide by Tulip's Table rate limits
• Avoid frequent writes to the same Record in a Table (more than 1/sec)

When thresholds are exceeded, Tulip may rate limit and return error code 429. Scripts should be made resilient to 429 error codes to try again after a delay.

Machine, device, and timer triggers

Low-interval timer triggers (every 1-2 seconds) can overwhelm your apps, especially when timer triggers include multiple API calls (i.e. table writes or connector function runs).

Machine triggers listen to attribute changes from connected equipment and execute logic in response. When machine attributes report at high-frequencies or when multiple attributes are monitored simultaneously, the trigger execution can exceed the rate at which the app processes the triggers. This can lead to performance degradation.

Recommendation

• Limit machine attribute subscriptions to only those that are necessary for the current step or workflow
• Separate high-frequency logic from cloud operations and use a lower-frequency trigger to handle cloud-dependent actions

Example scenario: A machine attribute updates 4 times per second, and you need to track the update count in a table record.
Trigger 1 (machine event): Update an app variable with incoming machine data
Trigger 2 (timer, every 10 seconds): Write accumulated data to a table record

• Consider using automations for asynchronous processing to remove the processing load from the trigger queue. For example, if machine data must be processed but does not require immediate operator feedback in the app session
• Use only fast operations in triggers, such as Read/update app variables or Read table records
• Evaluate your app architecture and consider redesigning it to operate at a lower rate if your use case requires monitoring many attributes at high frequencies. Alternative approaches include:
  • Aggregate data at the machine or edge device level before sending it to Tulip
  • Use Automations for data collection and processing
  • Reduce the reporting frequency at the data source
• Consider using Tulip Player drivers rather than Edge device-hosted drivers
  • Torque tool Player driver