Performance best practices（性能最佳实践）

This page describes best practices for optimizing performance and resource usage when configuring automations. Following these guidelines helps minimize compute consumption and ensures your automations run efficiently at scale.

:::callout{theme="info"} For general information about resource consumption in Foundry, see the resource management documentation. :::

Overview

Automate can become a source of high resource consumption if the configuration does not follow best practices. The general principle is to perform operations in bulk whenever possible.

Before creating an automation

Before setting up an automation, evaluate whether an Automate is actually needed:

• Use Automate when you need automated responses to data changes or scheduled processing that runs without manual intervention.
• You do not need Automate if you are manually changing object properties to hardcoded or computed values. In this case, create an Action type and invoke it directly from Workshop or Object Explorer on your target object set. This is more efficient and gives you direct control over when the action runs.

Understanding Automate's cost levers

There are three levers to consider when optimizing automation performance:

1. Condition configuration: What causes an automation to evaluate.
2. Execution mode: How condition events generate effect executions.
3. Effect design: What the action or function does when executed.

:::callout{theme="info"} Each lever build on the previous one. Execution modes and effects (Levers 2 and 3) can only be bulk if the automation condition (Lever 1) is configured for bulk operations. For example, if you condition on each individual object update, you will only have one object as input, forcing you to process objects one at a time. :::

Condition configuration (Lever 1)

The condition configuration determines how frequently your automation evaluates and processes objects.

• Frequently updating objects (100+ updates per day): For object types that update frequently, combine a time-based evaluation with your object set condition. This caps the number of automation evaluations at the frequency of the time condition.
• For infrequently updating objects: An object-update condition alone is sufficient.

Learn more about configuring conditions in the object set conditions documentation, time condition documentation, and about evaluation frequency options in the evaluation frequency documentation.

Example scenario

Consider an object type with 1,000 objects, where each object updates 100 times per day. Using only an "on object update" condition could result in up to 100,000 automation evaluations per day (100 updates × 1,000 objects, assuming updates do not occur simultaneously).

Adding a time condition of 5 minutes caps the maximum evaluations at 288 per day (1,440 minutes ÷ 5)—a reduction of up to 340×.

Execution mode (Lever 2)

Execution mode determines whether your automation processes all triggered objects together or creates separate executions for individual objects or batches. Learn more about execution settings. When configuring your automation's execution mode, prefer Single execution (the default) over per-object execution when your use case allows it.

• Single execution: The automation's effect runs once for all objects that match the condition, passing the full set of objects to the effect. This configuration processes all triggered objects in one automation run. This is usually more efficient than processing all objects individually.
• Per-object execution: The automation's effect runs separately for each object or batch. Use this when you have specific batching requirements that your business logic demands, such as needing to isolate failures or process objects with different configurations.

Learn more about execution modes in the object set conditions documentation.

Example scenario: An action that sends a notification per object and must include object-specific details can be implemented by a per-object-execution of an action that generate and send a notification for this object; or by calling a single-execution of one action that calls a function, which generate multiple notifications via a function. In this case, the second approach should be preferred.

Effect design (Lever 3)

The design of your action (and any backing function) determines whether you can take advantage of bulk processing. Design your actions to accept object sets as input parameters rather than single object references. This allows passing large numbers of objects efficiently in a single operation.

Learn more about configuring action parameters in the Action types documentation.

Summary of the input parameter types, from most to least efficient:

Input type	Efficiency	Description
Object set	Best	A queryable set of objects that can be passed efficiently regardless of size.
Object array	Good	An array of object instances; suitable for moderate-sized batches. Configure the parameter as "Object reference" with "allow multiple values" enabled.
Single object	Least efficient	A single object reference; use only when business logic requires it.

When your action is backed by a function, the function should also be designed to handle bulk inputs. For detailed guidance on writing performant functions, see Optimize function performance.

Key considerations:

• Accept object sets or arrays as input parameters.
• Perform bulk computations rather than iterating over objects individually.
• Use aggregations on the backend when possible instead of loading all objects into memory.

Monitoring your automations

Regular monitoring helps you identify and prevent performance issues. Watch for these warning signs:

• High execution frequency: Automations running many times per day
• Rapidly updating objects: Object types that update very frequently
• Deep automation chains: Multiple automations triggering each other
• Inefficient functions: Functions with per-object Ontology queries

If you notice any of these patterns, see Troubleshooting automation performance for detailed diagnosis and solutions.

Tools for monitoring

Use these tools to understand your automation behavior:

• Execution History in Automate: Available in your Automate configuration to view execution patterns
• Autopilot: Helps understand how automations chain together and their dependencies
• Workflow lineage: Traces automation dependencies across the platform

You can access Autopilot and Workflow Lineage through the Actions menu on your automation's Overview page.

Learn more about automation dependencies in the automation dependencies documentation.

---

中文翻译

性能最佳实践

本文档介绍了在配置自动化(Automation)时优化性能和资源使用的最佳实践。遵循这些指南有助于最大限度地减少计算消耗，并确保您的自动化能够高效地大规模运行。

:::callout{theme="info"} 有关 Foundry 中资源消耗的通用信息，请参阅资源管理文档。 :::

概述

如果配置未遵循最佳实践，自动化(Automate)可能会成为高资源消耗的来源。基本原则是尽可能进行批量操作。

创建自动化之前

在设置自动化之前，请评估是否确实需要自动化(Automate)：

• 何时使用自动化(Automate)： 当您需要对数据变更进行自动响应，或需要无需人工干预即可运行的定时处理时。
• 何时不需要自动化(Automate)： 如果您手动将对象属性更改为硬编码值或计算值，则无需使用自动化。在这种情况下，请创建一个操作类型(Action type)，并直接从 Workshop 或对象资源管理器(Object Explorer)对目标对象集调用它。这样效率更高，并且您可以直接控制操作的执行时机。

理解自动化的成本杠杆

优化自动化性能时，需要考虑三个杠杆：

1. 条件配置： 触发自动化评估的原因。
2. 执行模式： 条件事件如何生成效果执行。
3. 效果设计： 操作或函数在执行时执行的操作。

:::callout{theme="info"} 每个杠杆都建立在前一个杠杆之上。只有当自动化条件（杠杆 1）配置为支持批量操作时，执行模式和效果（杠杆 2 和 3）才能实现批量处理。 例如，如果您针对每个单独的对象更新设置条件，则每次只会有一个对象作为输入，从而迫使您逐个处理对象。 :::

条件配置（杠杆 1）

条件配置决定了自动化评估和处理对象的频率。

• 频繁更新的对象（每天 100 次以上更新）： 对于频繁更新的对象类型，请将基于时间的评估与对象集条件结合使用。这会将自动化评估次数上限限制为时间条件的频率。
• 对于不频繁更新的对象： 仅使用对象更新条件就足够了。

在对象集条件文档、时间条件文档中了解有关配置条件的更多信息，并在评估频率文档中了解有关评估频率选项的信息。

示例场景

假设有一个包含 1,000 个对象的对象类型，每个对象每天更新 100 次。仅使用"对象更新时"条件可能导致每天多达 100,000 次自动化评估（100 次更新 × 1,000 个对象，假设更新不会同时发生）。

添加一个 5 分钟的时间条件可将最大评估次数限制为每天 288 次（1,440 分钟 ÷ 5）——减少了多达 340 倍。

执行模式（杠杆 2）

执行模式决定了您的自动化是处理所有触发的对象，还是为单个对象或批次创建单独的执行。了解更多关于执行设置的信息。 在配置自动化的执行模式时，如果您的用例允许，请优先选择单次执行(Single execution)（默认设置），而不是按对象执行。

• 单次执行： 自动化的效果对所有匹配条件的对象运行一次，将完整的对象集传递给效果。此配置在一个自动化运行中处理所有触发的对象。这通常比逐个处理所有对象更高效。
• 按对象执行： 自动化的效果为每个对象或批次单独运行。当您的业务逻辑有特定的批处理要求时使用此模式，例如需要隔离故障或使用不同配置处理对象。

在对象集条件文档中了解有关执行模式的更多信息。

示例场景： 一个需要为每个对象发送通知且必须包含对象特定细节的操作，可以通过按对象执行一个生成并发送该对象通知的操作来实现；或者通过单次执行一个调用函数的操作来实现，该函数通过函数生成多个通知。在这种情况下，应优先采用第二种方法。

效果设计（杠杆 3）

您的操作（以及任何支持函数）的设计决定了您是否能够利用批量处理。将您的操作设计为接受对象集作为输入参数，而不是单个对象引用。这允许在单个操作中高效地传递大量对象。

在操作类型文档(Action types documentation)中了解有关配置操作参数的更多信息。

输入参数类型摘要，按效率从高到低排列：

输入类型	效率	描述
对象集(Object set)	最佳	一个可查询的对象集，无论大小如何都可以高效传递。
对象数组(Object array)	良好	对象实例的数组；适用于中等规模的批次。将参数配置为"对象引用(Object reference)"并启用"允许多个值(allow multiple values)"。
单个对象(Single object)	效率最低	单个对象引用；仅在业务逻辑要求时使用。

当您的操作由函数支持时，该函数也应设计为处理批量输入。有关编写高性能函数的详细指南，请参阅优化函数性能(Optimize function performance)。

关键考虑因素：

• 接受对象集或数组作为输入参数。
• 执行批量计算，而不是逐个迭代对象。
• 尽可能在后端使用聚合，而不是将所有对象加载到内存中。

监控您的自动化

定期监控有助于您识别和预防性能问题。请注意以下警告信号：

• 高执行频率： 自动化每天运行多次
• 快速更新的对象： 更新非常频繁的对象类型
• 深层自动化链： 多个自动化相互触发
• 低效的函数： 包含按对象进行本体查询(Ontology queries)的函数

如果您注意到任何这些模式，请参阅自动化性能故障排除(Troubleshooting automation performance)以获取详细的诊断和解决方案。

监控工具

使用这些工具来了解您的自动化行为：

• 自动化中的执行历史(Execution History in Automate)： 可在您的自动化配置中查看执行模式
• 自动导航(Autopilot)： 帮助了解自动化如何链接在一起及其依赖关系
• 工作流沿袭(Workflow lineage)： 跨平台追踪自动化依赖关系

您可以通过自动化概览(Overview)页面上的操作(Actions)菜单访问自动导航(Autopilot)和工作流沿袭(Workflow Lineage)。

在自动化依赖关系文档(automation dependencies documentation)中了解有关自动化依赖关系的更多信息。