Тестирование класса вершины и решил провести массовое тестирование, вставив 4000 записей учетной записи. Однако я получаю ошибку тайм-аута ЦП (время выполнения более 10 секунд), и часть этой ошибки, по-видимому, представляет собой время, которое требуется между триггером до вставки и триггером после вставки (около секунды, вы можете видеть, что он переходит от от 16 секунд до 18 секунд).

Bulk Load

Это стандарт или что-то ненормальное в моей организации? Я знаю, что между триггерами до и после происходят следующие шаги:

Повторно запускает большинство шагов проверки системы и выполняет повторяющиеся правила.

Дело даже не в том методе, который я пытался протестировать (так что проблема не в этом), а в том, что время ожидания истекло до этого. Я знаю, что мог бы пойти асинхронно, но это было задумано больше как стресс-тест организации. У кого-нибудь есть мысли о том, что может быть причиной выполнения 1-секундного промежутка?

3
Bobbygllh 31 Дек 2019 в 22:10
1
Это лучший журнал отладки? Обычно он также показывает время базы данных
 – 
Pranay Jaiswal
31 Дек 2019 в 22:35
Вы смотрели на жизненный цикл триггера («порядок выполнения») documentation, чтобы узнать, есть ли у вас какой-либо поток или построитель процессов или что-то еще, что вызывает эту задержку? Я бы также сказал, что написание «стресс-теста» в экосистеме Salesforce практически бессмысленно.
 – 
Phil W
31 Дек 2019 в 22:39
У меня есть и упомянул об этом в моем вопросе. Ни потоки, ни построители процессов не выполняются между триггерами «до» и «после». И я не согласен, я хотел бы сохранить возможность вставлять 4k учетных записей в организацию, если этого требуют требования.
 – 
Bobbygllh
31 Дек 2019 в 22:57
Да, у меня лучший уровень отладки для БД на
 – 
Bobbygllh
31 Дек 2019 в 23:03
У вас установлено много правил проверки или повторяющихся правил?
 – 
Kris Goncalves
31 Дек 2019 в 23:10

1 ответ

Лучший ответ

Время работы с базой данных не учитывается во времени процессора, даже если триггеры вызываются рекурсивно. Время базы данных здесь охватывает стандартные проверки (обязательные поля, повторяющиеся правила и т. д.), а также другие шаги, такие как вычисление формул и повторная загрузка записи из базы данных. Вам нужно будет сделать некоторое профилирование, чтобы выяснить, куда уходит дополнительное время. Обратите внимание, что процессы и потоки учитываются при расчете процессорного времени, поэтому, если у вас сложные потоки, они могут быть причиной проблемы.

5
sfdcfox 31 Дек 2019 в 23:29
Меня больше интересует недостающая секунда между триггерами до и после, это кажется очень длинным, верно? и только рабочие процессы, и они, похоже, не вызывают проблемы, 99,7% распределения времени вершины, 2,7% рабочих процессов
 – 
Bobbygllh
31 Дек 2019 в 23:42
Это постоянно так, или это может быть переменным? (Помните, что вы работаете в многопользовательской среде, и ваша организация будет работать, когда будут доступны ресурсы.)
 – 
Phil W
1 Янв 2020 в 00:09
Это не время «рабочего процесса», это просто время работы с базой данных. Я видел организации, которые постоянно имеют 2-4 секунды такого времени, которое может достигать 10 секунд. Это зависит от состязательности базы данных (блокировок), правил проверки, количества задействованных полей и записей, уровней отладки (максимальная отладка может легко увеличить время БД на 300%). Это не обязательно необычно.
 – 
sfdcfox
1 Янв 2020 в 01:09