Краткий ответ
Низкая производительность Salesforce является совокупным симптомом: страница записи с 14 компонентами, три автоматизации, запускаемые при одном сохранении, запрос, сканирующий миллион записей, и интеграция, извлекающая данные в часы пик. Единственный способ улучшить ситуацию без чрезмерных затрат бюджета — это послойное измерение, выявление доминирующего слоя и работа с ним, а затем повторное измерение.
Пять слоев и что измеряется в каждом
| Слой | Типичный симптом | Инструменты измерения | Типовое решение |
|---|---|---|---|
| Браузер и сеть | Замедление только у части пользователей | Lightning Usage App по пользователям | Корпоративная задержка, версия браузера, VPN |
| Экран и компоненты | Высокий EPT на центральной странице записи | EPT на страницу, режим отладки | Уменьшение числа компонентов, отложенная загрузка, вкладки |
| Автоматизация | Медленное сохранение, таймаут при массовом обновлении | Журналы отладки, сессии Flow | Объединение Flows, асинхронный переход |
| Данные и запросы | Отчеты не загружаются, List View зависает | Query Plan, Apex Jobs | Селективная фильтрация, индекс, архивация |
| Интеграция | Пиковые нагрузки в фиксированное время | Event Monitoring, использование API | Bulk API, окна выполнения, троттлинг |
Работа с большими объемами данных
При наличии более миллиона записей в объекте правила игры меняются. Перекос данных (Data Skew) — например, 200 тысяч учетных записей, связанных с одним владельцем или родителем — создает блокировки строк и замедляет любое массовое обновление. Решение заключается в распределении владения, а не в добавлении аппаратных средств, которые в любом случае находятся вне вашего контроля. Параллельно стоит рассмотреть архивацию: закрытые записи пятилетней давности, которые никто не читает, удорожают каждый запрос, выполняющий сканирование.
Экраны: меньше — значит быстрее
Средняя страница записи в зрелой организации накапливает два-три компонента в год, потому что каждый заинтересованный владелец просит "еще один виджет". Каждый компонент Lightning выполняет свои вызовы. Две операции приносят наибольшую выгоду: перемещение второстепенных компонентов на отдельные вкладки, которые загружаются только при нажатии, и применение видимости компонентов в зависимости от типа записи или роли, чтобы пользователь видел только то, что актуально для него. Сочетание этих двух подходов снижает EPT на десятки процентов без изменения кода.
Порядок действий, который работает
Начинается с недели измерений без изменений, чтобы установить надежный базовый уровень для пяти ключевых экранов и трех основных процессов. Затем обрабатываются экраны — это дешево и быстро. На третьем этапе объединяются автоматизации по объектам, и только на четвертом этапе затрагиваются запросы и модель данных. Интеграции обрабатываются параллельно, если измерения показали, что они являются причиной.
Логика такого порядка экономична: первые слои дешевы и обратимы, последние дороги и требуют регрессионного тестирования. Подробнее об этом можно прочитать в наших статьях Salesforce Health Check и Признаки необходимости обновления системы Salesforce.
Распространенные риски и профилактические меры
Большой риск — оптимизация без базового уровня: выполняются десять изменений, пользователи по-прежнему жалуются, и нет способа узнать, что помогло. Измерение до и после каждого значительного изменения — это необходимое условие, а не роскошь.
Второй риск — устранение самого громкого симптома. Экран, на который больше всего жалуются, не обязательно самый медленный — иногда он просто открывается чаще всего за день. Третий риск — изменение автоматизаций без тестового покрытия: объединение Flows — это действие с наибольшим потенциалом для скрытого нарушения бизнес-логики.
Как измеряется успех
Достаточно четырех метрик: средний EPT на пяти ключевых экранах, время сохранения в основном бизнес-процессе, количество сбоев по таймауту и лимитам платформы за месяц, а также доля запросов, длящихся более пяти секунд. Пятый показатель — дополнительный и нетехнический — это количество жалоб на производительность в Service Desk, которое должно уменьшаться по мере фактического улучшения.