Вы находитесь здесь:
Устранение ошибок Apex_CPU_TIME_LIMIT_EXCEEDED в потоках
Когда транзакция занимает слишком много процессорного времени, Salesforce выдает ошибку Apex_CPU_TIME_LIMIT_EXCEEDED. Потоки используют это ограничение совместно со всеми другими автоматизациями в одной транзакции, включая триггеры Apex.
Требуемые версии
| Просмотр поддерживаемых версий. |
| Требуемые полномочия пользователя | |
|---|---|
| Для открытия, редактирования, создания, активации или деактивации потока посредством всех типов потоков, элементов и функций, доступных в Flow Builder, включая Einstein и Agentforce for Flow: | Управление потоком |
| Для просмотра журналов отладки и доступа к ним: | Просмотр настройки и конфигурации |
| Для просмотра, сохранения и удаления журналов отладки и установки флагов трассировки: | Просмотр всех данных |
Salesforce применяет одно ограничение времени процессора 10 000 миллисекунд (10 секунд) на синхронную транзакцию. Каждый элемент автоматизации в этой транзакции, например, триггеры Apex, потоки, бизнес-правила и процессы, извлекается из одного бюджета. Если другая автоматизация использует большую часть бюджета первой, может произойти сбой даже оптимизированного потока. Порядок выполнения зависит от типа потока. Полный заказ см. в разделе Триггеры и порядок выполнения.
- Потоки до сохранения выполняются в порядке раньше, чем потоки после сохранения.
- Триггеры Apex выполняются до или после потоков, в зависимости от их типа триггера.
Для устранения неполадок и оптимизации потоков, достигающих ограничений по времени процессора:
- Понимание распространенных схем, приводящих к ошибкам ограничения процессора
- Определение элементов, потребляющих больше процессорного времени
- Применение методов оптимизации для сокращения расхода процессора
- Выполнение рекомендаций по профилактике во избежание ошибок ограничения процессора
- Проблемы, решения и методы профилактики ошибок ограничения процессора
Определите распространенные проблемы ограничения процессора, примените решения и выполните приемы профилактики, чтобы избежать ошибок Apex_CPU_TIME_LIMIT_EXCEEDED. - Определение элементов с интенсивным процессором в потоке
Используйте журналы отладки Apex для определения элементов в потоке, потребляющих больше процессорного времени.
См. также:
Проблемы, решения и методы профилактики ошибок ограничения процессора
Определите распространенные проблемы ограничения процессора, примените решения и выполните приемы профилактики, чтобы избежать ошибок Apex_CPU_TIME_LIMIT_EXCEEDED.
Данная таблица содержит ссылку на устранение ошибок ограничения процессора. Каждая строка описывает распространенную проблему, решение для ее устранения и приемы предотвращения в будущих потоках. Начните с определения применимости любой из этих проблем к потоку. Если таковые не применяются, другая автоматизация в той же транзакции — например, триггер Apex, другой поток или бизнес-правило — извлекает средства из того же бюджета процессора и может быть виновником. Чтобы определить расход процессора во всей транзакции, просмотрите журналы отладки Apex. Дополнительные сведения см. в разделе «Журналы отладки».
| Проблема | Решение | Метод профилактики |
|---|---|---|
Операции языка манипуляции данными (DML) внутри циклов Выполнение операций создания записей, обновления записей или удаления записей в пути цикла занимает процессорное время с каждой итерацией. Обработка нескольких записей по одной может быстро исчерпать ограничение. Пример: Поток обрабатывает 100 возможностей и использует элемент «Создание записей» в цикле для создания задачи для каждой возможности, что приводит к 100 отдельным операциям DML. |
Использование операций языка манипуляции данными на основе коллекции (DML) В цикле используйте элементы назначения для добавления записей в переменную коллекции записей. После завершения цикла используйте один элемент создания записей, обновления записей или удаления записей для обработки всей коллекции одновременно. Этот метод называется пакетированием. Пример: Циклируйте возможности, используйте элемент назначения для создания задачи для каждой возможности. Потом используйте другой элемент назначения для добавления каждой задачи к переменной коллекции. После цикла используйте элемент создания записей для создания всех задач одновременно. Подробнее см. в разделе «Пакетное выполнение потока в транзакциях». |
Не размещайте операции DML в циклах. Всегда проектируйте потоки для сбора записей в переменной коллекции во время цикла, потом выполняйте DML после завершения цикла. |
Несколько запросов внутри циклов Элементы получения записей внутри цикла потребляют значительное процессорное время, особенно при запросе больших объектов или использовании сложных фильтров. Пример: Поток выполняет цикл по организациям и использует получение записей внутри цикла для получения связанных контактов для каждой организации, что приводит к одному запросу на организацию. |
Запрос данных перед циклами Перед циклом используйте один элемент получения записей и используйте функцию получения связанных записей для получения всех необходимых данных с соответствующими фильтрами. Во время цикла используйте собранные данные, а не запросы по каждой итерации. Если вы не можете использовать один элемент получения записей, используйте элемент получения записей для получения основных записей. Потом используйте другой элемент получения записей для получения дополнительных записей. Фильтруйте дополнительные записи посредством поля записи, оператора In и первой коллекции получения записей. Например, «Код организации > В > Организации из получения организаций». Пример: Сперва получите все связанные контакты с элементом получения записей, фильтрующим по кодам организаций, потом сошлитесь на коллекцию контактов во время цикла. |
Избегайте запросов внутри циклов. Получите все необходимые данные перед входом в цикл. |
Сложные формулы в циклах Элементы назначения, выполняющие сложные вычисления формулы на каждой итерации цикла, накапливают процессорное время, особенно с манипуляциями строками, вычислениями дат или вложенными функциями. Пример: Поток прокручивает 500 записей, и каждая итерация выполняет несколько вычислений формул для получения значений полей. |
Упрощение формул Разделите сложные формулы на более простые этапы. Вычислите значения, которые не меняются вне цикла. При возможности избегайте вложенных функций. Рекомендуем использовать поля формул в объекте вместо формул потока. Для операций над целыми коллекциями (например, фильтрация, соотнесение или сортировка) элемент трансформации выполняется более эффективно, чем цикл. Чтобы получить все связанные записи в одном запросе вместо одного запроса на цикл итерации, используйте элемент получения записей с оператором IN. Дополнительную информацию см. в разделе «Элемент трансформации». |
Упростите формулы и переместите вычисления, которые не меняются вне цикла. Протестируйте производительность формулы с помощью реалистичных объемов данных. |
Обработка больших коллекций записей Запланированные потоки или пакетные операции, обрабатывающие тысячи записей в одной транзакции, даже при правильном пакетировании, могут занять слишком много процессорного времени. Пример: Запланированный поток получает 5000 записей организаций и выполняет сложные трансформации над данными каждой записи, прежде чем обновить их. |
Использование альтернативных подходов Для больших объемов данных учитывайте следующее:
|
Фильтруйте данные на раннем этапе, чтобы сократить количество обрабатываемых записей. Используйте фильтры получения записей для получения только нужных записей. Протестируйте реалистичные объемы данных перед развертыванием в производстве. |
Несколько потоков в транзакции Когда один поток запускает другие потоки (посредством изменений записи или подпотоков), общее время процессора всех потоков в транзакции учитывается в ограничении. Пример: Поток, запущенный записью, в обновлениях организации выполняет несколько подпотоков, а также запускает другие потоки, запущенные записью, в связанных объектах. |
Сокращение цепочек потоков Консолидируйте связанную автоматизацию в меньшем количестве потоков. Просмотрите критерии триггера потока, чтобы обеспечить выполнение потоков только при необходимости. Рекомендуем использовать условия входа для ограничения времени выполнения потоков, запущенных записью. |
Просмотрите совокупное влияние всей автоматизации (потоки, процессы, бизнес-правила, триггеры), которая может выполняться в одной транзакции. Мониторинг и оптимизация всей цепочки автоматизации. |
Пакетные загрузки данных Потоки, запущенные записью, выполняемые во время пакетного импорта данных или пакетного обновления, требуют эффективной обработки всех записей. Неэффективные потоки достигают ограничений процессора во время пакетных операций, даже если они хорошо работают для отдельных записей. Пример: Пользователь импортирует 200 записей организаций. Поток, запущенный записью до сохранения, выполняет несколько поисков и расчетов для каждой организации. |
Оптимизация для пакетных операций
Дополнительную информацию см. в разделе «Элемент трансформации». |
Всегда считайте, что потоки, запущенные записью, обрабатывают несколько записей одновременно. Протестируйте пакетные загрузки данных (посредством Data Loader или пакетных обновлений) перед развертыванием в производстве. При неправильном проектировании поток, идеально работающий для отдельных записей, может не выполниться во время пакетных операций, если не создать его надлежащим образом. |
Общие рекомендации по профилактике
- Отслеживание производительности потока: Регулярно просматривайте журналы отладки Apex, чтобы определить потоки, приближающиеся к ограничениям процессора, даже если они еще не вышли из строя. Регулярное отслеживание помогает оптимизировать потоки, прежде чем они приведут к проблемам в производстве.
- Тестирование с реалистичными данными: Протестируйте потоки с реалистичными объемами данных для обнаружения проблем производительности перед активацией. Режим отладки обычно тестируется с одной записью, что не обнаруживает проблем с пакетными операциями.
- Решения оптимизации документа: Используйте описания элементов, чтобы отметить, где вы применили пакетирование или другие оптимизации. Эта документация помогает будущим обслуживающим понять дизайн и предотвращает случайное возникновение проблем с производительностью.
- Начните просто и оптимизируйте: Создавайте потоки небольшими инкрементами, тестируя производительность на каждом этапе. Оптимизировать рабочий поток проще, чем исправить сложный поврежденный.
Определение элементов с интенсивным процессором в потоке
Используйте журналы отладки Apex для определения элементов в потоке, потребляющих больше процессорного времени.
- Перейдите в настройки и введите строку «Журналы отладки» в поле «Быстрый поиск».
- Настройте журнал отладки для пользователя, у которого произошла ошибка, или выполните поток в режиме отладки.
- Воспроизведите ошибку, выполнив поток.
- Откройте созданный журнал отладки.
-
Найдите эти ключевые события в журнале отладки.
FLOW_CREATE_INTERVIEW_BEGIN- Отображает время начала каждого потокаFLOW_ELEMENT_LIMIT_USAGE- Отображает расход процессорного времени для каждого элемента потокаCUMULATIVE_LIMIT_USAGE- Отображает общее время выполнения процессора
-
Определите элементы с высокими значениями времени процессора.
Распространенные виновники включают:
- Элементы цикла с большими коллекциями.
- Получение элементов записей с помощью сложных фильтров.
- Операции DML с несколькими записями («Создание записей», «Обновление записей», «Удаление записей»).
- Элементы назначения со сложными формулами.
Теперь вы знаете, какие элементы занимают больше процессорного времени. Используйте эти сведения для применения целевых оптимизаций.
Дополнительные сведения о журналах отладки см. в разделе «Работа с журналами на консоли разработчика».
