本指南概述了设计高性能 Tulip 应用程序的最佳实践，这些应用程序可在生产环境中高效扩展。遵循这些建议将有助于确保您的应用程序在业务规模扩大时仍能保持响应迅速且运行稳定。
:::(信息) (注)
本文中的建议适用于您的解决方案中使用连接器函数连接Tulip API的所有场景。这些场景包括：
- 在应用级触发器（例如定时器、按钮、步骤进入）上运行的连接器函数或API Call
- 来自 Node-RED 的 API 调用
- 包含源自 Tulip 解决方案外部的 API 调用的脚本
- 从其他系统使用表 API 向 Tulip 表写入数据
:::
什么是高频触发器？
高频触发器执行频率高于每 5 秒一次（快于 0.2 Hz）。机器属性事件、设备事件和定时器触发器是导致高频执行的最常见来源。
为保持应用程序的性能和响应速度，Tulip 建议触发器的执行频率不超过 5 秒（0.2 Hz）。
触发器队列的影响
应用程序触发器在称为“触发器队列”的顺序单线程队列中自上而下执行。
以下两个因素决定了队列能否高效运行：
- 队列入队速率：触发事件被添加到队列的频率
- 队列退出率：触发逻辑完成执行的速度
当触发器进入队列的速度快于退出速度时，队列就会积压。触发器队列的持续积压会导致应用延迟，在某些情况下甚至会导致触发事件丢失。
可以将触发器的频率比作高速公路上的车流。如果在短时间内有太多车辆驶入高速公路，车流就会变慢。为了避免拥堵，车辆的进入速度必须控制在高速公路能够承受的范围内。
综合频率
应用中所有触发事件的总频率决定了整体队列入队速率。您配置的每个触发事件都会增加这一总频率。
请参阅下表中的组合频率示例：
| 配置 | 合并频率 |
|---|---|
| 每1秒更新1个机器属性 | 1Hz |
| 每1秒更新5个机器属性 | 5Hz |
| 1个设备属性（1秒）+ 1个定时器（2秒） | 1.5Hz |
触发逻辑速度等级
触发逻辑的类型决定了触发器从队列中移出的速度。需要云通信、状态转换或外部系统响应的逻辑，其运行时间比本地操作要长得多。
下表描述了不同类型逻辑的速度。
For high-frequency triggers, aim to use only logic rated Very fast or Fast.
| 速度 | 逻辑类型 | 示例 |
|---|---|---|
| 非常快 | 本地应用程序逻辑 | 读取或更新本地数据（例如变量） |
| 快速 | 缓存的云端数据 | 读取已加载的表记录 |
| 中等 | Tulip Cloud | 加载、更新或创建表记录；读取或更新机器状态 |
| 慢 | Tulip Cloud | 表聚合和查询 |
| 非常慢 | 外部系统 | 连接器函数 |
There is currently no easily accessible app performance log available for evaluating trigger performance. App performance can only be inferred through step times in completion records, which is useful in cases where steps involve extensive looping.
影响触发器性能的技术因素
- 本地硬件——触发器逻辑在本地硬件上执行，因此设备规格会显著影响触发器完成并退出队列的速度。有关设备规格，请参阅《Tulip Player 推荐设备》。
- 外部依赖项——外部依赖项包括与云端的连接、本地网络延迟，以及企业资源规划（ERP）等外部系统的响应时间。
- 通过 Tulip Edge 设备连接的设备——Tulip 应用依赖于云连接，这可能会引入延迟。例如，连接到边缘设备的扭矩控制器仍需通过 Tulip 云服务与 Tulip Player 进行通信。要了解设备连接情况，请参阅这些关于通过 Tulip 驱动程序进行设备连接的序列图。
- 连接器函数的延迟问题- 通过连接器函数从系统（例如 ERP）获得的响应缓慢，可能会导致应用程序延迟，特别是当应用程序循环处理大量记录时，每条记录都可能需要长达两秒的 API 调用。要了解系统连接，请参阅这些连接到企业系统的序列图。
- 车间与 Tulip 云基础设施之间的延迟——为最大限度地降低延迟，您的 Tulip 实例应部署在与车间相同的地理区域内。
指导建议
避免使用高频触发器
应尽可能避免使用高频触发器，而应采用其他功能，例如Automation。
您可能还需要重新设计应用程序架构，使其以较低的频率运行。例如：* 通过查询和聚合减少数据报告的频率* 对于异步用例，可通过“自动化”实现循环操作* 对于同步用例，必须按顺序执行的循环应通过“函数”实现
如果必须使用高频触发器，应将其配置为仅执行本地操作（例如更新应用变量）。然后，使用低频触发器来执行较慢的操作（例如更新表记录）。
如果您正在使用高频定时器触发器来快速响应 Tulip 应用外部的上下文，则可以使用带有机器和设备触发器的“事件流”Tulip Machine。
Tulip 表 API 的使用
每秒多次使用表 API 进行读写操作可能会影响实例性能，并导致数据读取或存储延迟。以下建议适用于在 Tulip 实例上运行 Tulip API 的所有脚本和触发器操作：
建议
- 规划逻辑执行以遵守 Tulip的表速率限制
- 避免频繁（超过每秒 1 次）向表中的同一条记录写入数据
当超过阈值时，Tulip 可能会实施速率限制并返回错误代码 429。脚本应具备对 429 错误代码的容错能力，以便延迟后重试。
机器、设备和定时器触发器
低间隔定时器触发器（每 1-2 秒一次）可能会导致应用程序过载，特别是当定时器触发器包含多个 API 调用（例如表写入或连接器函数运行）时。
Tulip no longer supports a timer trigger with <30sec frequency. For timer triggers used in an event-based architecture (i.e. a table record field changed or the current time is 7:00am), we recommend using Machines or [Automations]. Contact your Tulip representative if you have questions about this transition.
机器触发器会监听来自连接设备的属性变化，并据此执行相应逻辑。当machine attributes 以高频率报告数据，或同时监控多个属性时，触发器的执行速度可能会超过应用程序处理触发器的速度。这可能会导致性能下降。
建议
- 将machine attribute 订阅限制为仅包含当前步骤或工作流所必需的那些
- 将高频逻辑与云端操作分离，并使用低频触发器来处理依赖云端的操作
示例场景：某machine attribute 每秒更新4次，您需要跟踪表记录中的更新次数。触发器1（机器事件）：使用传入的机器数据更新应用变量；触发器2（定时器，每10秒一次）：将累积数据写入表记录
| 方法 | 配置 | 性能 |
|---|---|---|
| 最优 | 机器触发器递增应用变量；定时器触发器每10秒将数据写入表记录 | 良好（云端运行频率为0.1 Hz） |
| 较慢 | 机器触发器在每次更新时直接写入表 | 较差（云端运行频率为 4 Hz） |
- 建议使用自动化流程进行异步处理，以减轻触发器队列的处理负担。例如，如果必须处理机器数据，但应用会话中无需立即向操作员提供反馈
- 在触发器中仅使用快速操作，例如读取/更新应用变量或读取表记录
- 如果您的用例需要高频监控多个属性，请评估应用架构并考虑重新设计，使其以较低的速率运行。替代方案包括：
- 在将数据发送至 Tulip 之前，先在机器或边缘设备层面进行数据聚合
- 使用自动化功能进行数据采集和处理
- 降低数据源的报告频率
- 考虑使用 Tulip Player 驱动程序，而非由边缘设备托管的驱动程序
- Torque 工具 Player 驱动程序
