Схемы масштабируемости
Узнайте больше о надежности → Масштабируемость и планирование нагрузки
Шаблоны
| Где искать | Как хорошо выглядит |
|---|---|
| Эффективность запросов SOQL | Консолидируйте запросы посредством запросов взаимосвязи (Контакты, обращения__r) вместо отдельных запросов на связанный объект. Запросите все нужные данные один раз на транзакцию. Цель <50 запросов в синхронных транзакциях, <100 в асинхронных (ограничения: 100 синхронизаций, 200 асинхронизаций). Поддерживайте 30-50% буфера ниже ограничений. |
| Пакетное выполнение операций DML | Собирайте записи в списки, выполняйте один оператор DML на тип объекта на транзакцию. Используйте Database.insert/update/delete с параметром allOrNone, контролирующим алгоритм частичного успеха. Цель <75 операторов DML на транзакцию (ограничение: 150). Пакет уменьшает потребление DML с N операторов до 1. |
| Управление размером кучи | Запрос только обязательных полей (избегайте шаблонов «ВЫБРАТЬ*»). Обработка больших наборов результатов фрагментами. Очистите коллекции после обработки, чтобы освободить память. Цель <4 Мб кучи в синхронном контексте (ограничение: 6 Мб), <8 Мб асинхронный (ограничение: 12 МБ). Превышенные ошибки кучности указывают на необходимость фрагментации или потоковых схем. |
| Оптимизация процессорного времени | Уменьшите сложность вычислений в циклах. Используйте соотнесения для поиска (O(1)) вместо вложенной итерации списка (O(n2)). Загрузите тяжелые вычисления в асинхронный контекст. Цель <7,000ms CPU в синхронных транзакциях (ограничение: 10 000мс), <40 000мс асинхронный (предел: 60 000ms). |
| Строки запросов SOQL | Создайте запросы, возвращающие разумные размеры набора результатов. Используйте условие LIMIT для ограничения результатов. Цель <25 000 строк на запрос в синхронном контексте (ограничение: 50,000). Запросы, приближающиеся к ограничениям, должны использовать пагинацию или перейти к асинхронной обработке с помощью пакетного Apex или «В очереди». |
| Распределение вызовов API | Отслеживайте круглосуточное ограничение потребления API посредством общих сведений о системе. Пакетные операции API вместо вызовов по записи. Кэширование часто используемых справочных данных посредством кэша платформы. Цель <70% ежедневного ограничения API для размещения скачков. Ограничение API зависит от выпуска и количества лицензий. |
| Ограничения выноски | Консолидация внешних выносок: пакетирование нескольких записей в один запрос API при его поддержке внешней системой. Внедрите очередь запросов для сериализации выносок. Соблюдайте 120-секундное общее время выноски на транзакцию. Ограничение: 100 выносок на транзакцию. Создайте обработку асинхронизации для интеграций с высокой выноской. |
| Код (Apex, Aura, LWC) | Внедрение пакетных схем: обрабатывать коллекции не отдельных записей, запрашивать один раз и кэшировать в картах, выполнять один DML на тип объекта. Используйте запросы взаимосвязи для минимизации потребления SOQL. Применяйте эффективные алгоритмы, избегая вложенных циклов в больших наборах данных. |
Антишаблоны
| Где искать | Как плохо выглядит |
|---|---|
| SOQL в циклах | Проблема: Выполнение запросов SOQL внутри для циклов обработки коллекций записей. Влияние: Превышено ограничение по количеству запросов при 100+ записей (ограничение: 100 запросов на транзакцию). Резолюция: Запросите один раз перед циклом, сохраните результаты в соотнесении, ключ по полю взаимосвязи. Поиск по карте внутри цикла (схема пакетирования). |
| DML в циклах | Проблема: Выполнение операторов вставки/обновления/удаления внутри для циклов. Влияние: Превышено ограничение DML при 150+ записях (ограничение: 150 операторов DML на транзакцию). Резолюция: Собирайте записи в список внутри цикла, выполняйте одно оператор DML после завершения цикла. |
| Отсутствие буфера ограничения губернатора | Проблема: Разработка транзакций, потребляющих 95%+ контролирующих ограничений в обычных условиях. Влияние: Производственные сбои во время незначительного увеличения нагрузки, нет нагрузки для краевых случаев. Резолюция: Целевое значение 70% ограничений в качестве операционного потолка. Зарезервируйте 30% буфера для шипов и краевых обращений. |
| Вложенные декартовы продукты цикла | Проблема: Вложенные циклы, инициирующие две большие коллекции, создающие операции O(n2). Влияние: Превышено ограничение процессора, превышено ограничение кучности от временных объектов. Резолюция: Используйте поиски на основе карты, преобразующие O(n2) в O(n). Соберите ключи внешнего цикла, запросите связанные записи один раз, поиск во внутреннем цикле. |
| Накопление кучи | Проблема: Загрузка больших запросов в память без обработки фрагментами. Влияние: Превышено ограничение по кучности (6 Мб синхронизации, 12 Мб асинхронизации). Резолюция: Запрос только нужных полей. Обработка в коллекциях пакетной очистки после каждого пакета. Используйте QueryLocator с пакетным Apex для многомиллионной обработки записей. |
| Отсутствие фильтрации на уровне поля | Проблема: Выбор всех полей (явных или скрытых), если требуется только поднабор. Влияние: Чрезмерное потребление кучи, замедление выполнения запроса, неоправданный подход к ограничению строк SOQL. Резолюция: ВЫБЕРИТЕ только поля, обязательные для обработки. Используйте запись взаимосвязи для извлечения связанных данных в одном запросе, а не в отдельных запросах. |
| Чрезмерное использование синхронной обработки | Проблема: Синхронная обработка больших объемов данных в транзакциях пользователя. Влияние: Пользователь, ожидающий многосекундных операций, превышено ограничение по количеству процессоров/кучи блокировки пользователя. Резолюция: Переместите тяжелую обработку в асинхронный контекст (пакет, очередь, события платформы). Предоставьте пользователям немедленный ответ посредством опроса статуса. |
Шаблоны
| Где искать | Как хорошо выглядит |
|---|---|
| Асинхронная обработка | Используйте пакет Apex для обработки больших объемов записей (миллионов). Используйте Queueable Apex для сложной многоэтапной оркестрации с цепочкой. Используйте события платформы для развязки под управлением событий. Используйте запланированный Apex для периодического обслуживания. Соотнесите схему асинхронизации со сценарием использования: Пакетирование для объема, постановка в очередь для сложности, события для развязки. |
| Пакетное внедрение Apex | Создайте метод запуска, возвращающий выборочный QueryLocator для минимизации обрабатываемых записей. Настройте размер пакета на основе сложности записи (200-2000 записей на выполнение). Внедряйте штатный интерфейс только при необходимости, поскольку он уменьшает производительность. Отслеживайте AsyncApexJob на наличие успеха/сбоя. Пакет предоставляет выделенные контролирующие ограничения на фрагмент. |
| Архитектура событий платформы | Публикация событий для изменений состояния, требующих последующей обработки. Подпишитесь с помощью триггеров Apex на объекты событий платформы или внешних подписчиков посредством CometD. Создайте мощных подписчиков (повтор может предоставлять события несколько раз). Используйте 72-часовое сохранение для восстановления после временных сбоев подписчика. |
| Разделение на основе даты | Обработка данных во временных окнах: текущий месяц, последний квартал, текущий год. Архивирование архивных данных в большие объекты или внешнее хранилище. Разделение на основе времени включает параллельные пакетные задания, обрабатывающие разные диапазоны дат одновременно. Большинство запросов, естественно, фильтруются по дате, что делает их эффективными. |
| Разделение типа записи | Отдельно обрабатывайте разные типы записей. Запланируйте отдельные пакетные задания на каждый тип записи, включив параллелизацию. Типы записей часто коррелируют с разными бизнес-процессами, оправдывающими независимую обработку. Не более 5 параллельных пакетных заданий на организацию требуют стратегического разделения. |
| Разделение на основе географии | Разделение по ответственному, подразделению или территории для обработки распространения. Обработайте каждый регион, бизнес-единицу или территорию продаж в параллельных пакетных заданиях. Модель общего доступа к разделению на основе географии: каждое пакетное задание выполняется в контексте определенной группы пользователей, естественно фильтрующей данные. |
| Стратегия кэширования | Используйте кэш платформы (разделы организации/сеанса) для часто используемых справочных данных. Кэш уменьшает потребление запросов и API. Распределите разделы организации и сеанса с шагом в несколько Мб; стандартная нагрузка зависит от выпуска, дополнительная емкость приобретается блоками. Пропуск кэша должен изящно вернуться к запросу. Кэш TTL должен соответствовать частоте изменения данных: часы для статических справочных данных, минуты для полудинамических. |
| Пакетное выполнение потока | Создание потоков обработки коллекций записей посредством переменных «Цикл» и «Коллекция». Создайте коллекцию записей, выполните однократное получение записей, обновите коллекцию посредством одного элемента обновления записей. Избегайте отдельных операций записи в циклах. Схемы пакетирования потоков повторяют рекомендации Apex. |
Антишаблоны
| Где искать | Как плохо выглядит |
|---|---|
| Только последовательная обработка | Проблема: Одна пакетная обработка всех 50 миллионов записей последовательно занимает 24+ часов. Влияние: Блокирует другую обработку, исчерпание окна обслуживания, задержки, ориентированные на пользователя. Резолюция: Данные разделения по дате, типу записи или географии. Выполнение параллельных пакетных заданий одновременной обработки независимых разделов. |
| Зависимости синхронной интеграции | Проблема: Транзакции пользователя заблокированы в ожидании ответов внешней системы посредством синхронных выносок. Влияние: Взаимодействие пользователя, связанное с производительностью внешней системы, сбои времени ожидания во время внешних сбоев. Резолюция: Используйте события платформы для асинхронной интеграции. Разделите транзакцию пользователя от доступности внешней системы. |
| Нет слоя кэширования | Проблема: Многократный запрос одних и тех же справочных данных в транзакциях. Влияние: Чрезмерное потребление SOQL, отходы ограничения API, замедление выполнения транзакций. Резолюция: Внедрите кэш платформы для часто используемых справочных данных. Кэш уменьшает ограничение потребления и повышает производительность. |
| Пакетное укладывание заданий | Проблема: Планирование пакетных заданий 20+, начинающихся одновременно. Влияние: Наращивание глубины очереди, ограничение 5 параллельных заданий приводит к сериализации, непредсказуемому времени выполнения. Резолюция: Поэтапное планирование распределения нагрузки по часам. Объедините похожие задания в один пакет посредством динамической логики отправки. |
| Состоятельное переиспользование пакета | Проблема: Внедрение пакетного Apex с базой данных.Stateful, если не требуется. Влияние: Ненужная сериализация переменных участников экземпляра в вызовах выполнения() и потенциальное накопление куч из сохраненного состояния. Резолюция: Используйте stateful только в том случае, если состояние должно сохраняться в вызовах выполнения. Отдавайте предпочтение пакетам без гражданства, чтобы избежать ненужной сериализации состояния над головой. |
| Однопоточное оформление потока | Проблема: Поток обрабатывает записи по очереди в цикле с отдельными элементами получения/обновления записи на итерацию. Влияние: Ограничение потребления управляющим пропорционально количеству записей, сбоям транзакций в масштабе. Резолюция: Собирайте записи в переменную коллекции, выполняйте однократное получение записей, обновляйте коллекцию с одним элементом обновления записей вне цикла. |
| Нет стратегии повторной синхронизации | Проблема: Неудачные асинхронные задания не выполняются автоматически повторно, что требует ручного вмешательства. Влияние: Несоответствия данных, операционная нагрузка вручную, SLA пропускает. Резолюция: Внедрите автоматическое повторение с экспоненциальным отступлением. Используйте события платформы для долговременной очереди, включающей повтор. Отслеживайте AsyncApexJob и предупреждайте об устойчивых сбоях. |
Шаблоны
| Где искать | Как хорошо выглядит |
|---|---|
| Выбор пакета и очереди | Используйте пакет Apex для: обработка миллионов записей фрагментами, запланированные пакетные операции, миграции данных. Используйте Queueable Apex для: многоэтапные бизнес-процессы интеграции с цепочкой, операции, требующие параметров сложного объекта, задания, требующие лучшего мониторинга, чем @future. Async Apex использует ограничение 250 000 выполнений в сутки (DailyAsyncApexExecutions) в пакетном, очередном, будущем и запланированном Apex, а не в распределении, характерном для очереди. |
| Цепочка очереди | Внедрите многоэтапные бизнес-правила, поставив следующее задание в очередь из метода выполнения текущего задания. Цепочка включает последовательную обработку: выноска → анализ ответа → последующее действие очереди. Максимальное количество 1 очереди на выполнение в очереди предотвращает цепочки побегов. Создайте цепочки с обнаружением завершения, чтобы избежать бесконечных циклов. |
| Использование метода @future | Используйте @future для простых операций асинхронизации, не требующих сложных параметров (только простых) и цепочки. Ограничение: 50 @будущих вызовов на транзакцию Apex. @будущее предоставляет простейшую схему асинхронизации, но недоступно: нет мониторинга заданий, цепочки, сложных параметров. Предпочтение создания очереди. |
| Запланированная оптимизация Apex | Объедините запланированные операции в единый запланированный класс, отправляющий определенным обработчикам. Максимальное количество запланированных заданий на организацию требует стратегической консолидации. Планируйте в нерабочее время, чтобы уменьшить споры с операциями пользователя. Используйте запланированный Apex для оркестрации, делегируйте тяжелую обработку пакетному Apex. |
| Повтор события платформы | Создайте подписчиков, обрабатывающих сценарии повтора: повторяющиеся события после сбоя подписчика, события разрыва после длительного отключения. Сохранение последнего обработанного ReplayId на подписчика. Используйте EventBus.getReplayId() для обнаружения повтора и новых событий. Внедрите идемпотентную обработку (обработка одного события дважды приводит к одному результату). |
| Схема продолжения | Используйте «Продолжение» для долгосрочных выносок из компонентов Lightning, требующих >5 секунд времени ответа. Продолжение включает несколько одновременных 120-секундных выносок, улучшающих воспринимаемую производительность для параллельных операций. Ограничение: 3 продолжения на запрос. Внедрите обработку времени ожидания и отзывы пользователей. |
Встроенные примеры и подробные рекомендации см. в столбе «Надежность» или в проводнике по схемам и антипаттернам.