Вы находитесь здесь:
Общие сведения об оптимизации данных и производительности в Salesforce Spiff
Конструктор и механизм комиссии используют одну и ту же базовую логику, то есть решения, принимаемые во время настройки, напрямую влияют на производительность оператора в масштабах.
Конструктор и механизм комиссии
Конструктор и механизм комиссии в своей основе похожи, но служат разным целям. Конструктор использует механизм комиссии для отображения результатов расчета в режиме реального времени, как электронная таблица. Механизм комиссии рассчитывает операторы изолированно, с фиксированным объемом памяти и времени, выделенным для каждого оператора.
Данная таблица отображает ключевые характеристики каждого из них.
| Конструктор | Механизм комиссии |
|---|---|
| Отображает результаты расчета в режиме реального времени по мере создания, подобно электронной таблице. | Создание окончательных отчетов по комиссиям, каждый из которых рассчитывается отдельно от других. |
| Использует комиссионный механизм под капотом, поэтому его поведение отражает действия двигателя в производстве. | Обрабатывает заявления без гарантированного порядка — заявление одного представителя не блокирует или не влияет на заявление другого. |
| Ошибки времени ожидания в конструкторе обозначают, что та же логика создает давление производительности в производстве. | Каждый оператор получает фиксированное распределение памяти и времени обработки. |
| Ошибки времени ожидания или памяти в конструкторе - это сигнал для оптимизации, но они не всегда указывают на проблему с расчетом оператора. Поскольку ограничения конструктора ниже, в конструкторе могут отображаться ошибки, которые не отображаются при выполнении той же логики, что и оператор. | Если оператор превышает установленное ограничение, обратитесь в службу поддержки Salesforce за увеличением памяти или временных ограничений. |
| Хороший прокси-сервер на ранних этапах для производительности производства — если время его действия истекает в конструкторе, он испытывает трудности в движке. В больших, более сложных планах ошибки конструктора могут быть неизбежны. В этих случаях успешные вычисления оператора являются подходящей целью, поскольку успех конструктора не всегда достижим или обязателен. | Для составления отчетов доступны только данные, сохраненные в разделе «Сбор трассировки». Выключение трассировки поля инициирует его удаление из отчетов и экспортов. |
Поскольку Designer работает под более низкими ограничениями памяти и обработки, чем механизм комиссии, время ожидания в Designer является полезным сигналом для изучения и оптимизации, но это не всегда значит, что расчет оператора не удастся. В меньших конфигурациях время ожидания в конструкторе часто указывает на трудности с той же логикой в масштабе оператора. В больших или более сложных планах время ожидания конструктора может наступить даже при успешном вычислении эквивалентного оператора.
Если оператор превышает объем памяти или времени, доступны два пути: Обратитесь в службу поддержки Salesforce для запроса увеличения ресурса или оптимизации логики плана и фильтров данных. На практике увеличение ресурсов часто является самым быстрым решением, когда проблема обнаруживается близко к выполнению платежной ведомости. Оптимизация устраняет основную причину и является рекомендуемой последующей мерой, если увеличение ресурса само по себе не решает проблему, или долгосрочной стратегией сокращения потребления ресурсов оператора.
Например, создайте вычисляемое поле в объекте «Возможности», использующее функцию sum() для агрегации годового регулярного дохода (ARR) по всем закрытым возможностям представителя. При предварительном просмотре оператора в конструкторе для отдельного представителя с двухлетней историей, время расчета истекает. Если время ожидания истекает в конструкторе, комиссия сталкивается с той же проблемой — и, вероятно, в большем масштабе — когда она обрабатывает выписки для всей рабочей группы представителя за один запуск. Исправление заключается в оптимизации расчета перед переходом к производству: выключить трассировку поля sum(), инкапсулировать его в виде отдельного расчета рабочего листа или заменить полное журнальное сканирование отфильтрованным диапазоном данных.
На чем сосредоточить усилия оптимизации
Повышение производительности в Spiff происходит из трех областей: способ поступления данных в систему, способ обработки этих данных логикой плана и настройка отображения полей на странице выписки. Совместное рассмотрение всех трех аспектов дает наилучшие результаты.
Сосредоточьте усилия оптимизации на этих трех уровнях.
- Слой данных. Оптимизируйте фильтры данных, уменьшите объемы записей посредством фильтрации в восходящем направлении (в исходных системах) и поймите схему и взаимосвязи между объектами. См. разделы Оптимизация производительности фильтра данных в Salesforce Spiff и Снижение загрузки механизма комиссии посредством первичных изменений данных.
- Слой логики планирования. Инкапсулируйте вычисления, отключите трассировку там, где она не нужна, и используйте таблицы поиска и динамическую логику вместо жестко запрограммированных значений или сложных вложенных формул. См. разделы Использование капсуляции в расчетах Salesforce Spiff и Использование таблиц поиска и динамической логики в Salesforce Spiff.
- Конфигурация страницы оператора. Ограничьте поля на странице выписки тем, что активно нужно видеть представителям, и удалите промежуточные расчеты и диагностические поля из представления представителя. Механизм комиссии запускает все видимые поля для каждого оператора — даже поля, которые иначе не встретились бы механизму на пути вычисления.
Принципы производительности
Учитывайте эти руководящие принципы в процессе внедрения.
- Начните оптимизацию в первый день и регулярно пересматривайте ее. Переоборудовать улучшения производительности в существующую конфигурацию сложнее, чем встраивать их с самого начала. Логика плана и объемы данных меняются с течением времени, поэтому встройте проверку производительности в цикл обслуживания регулярного плана, а не только в исходное внедрение.
- Консолидируйте и агрегируйте данные до их поступления в механизм. Структурируйте данные таким образом, чтобы представители работали со значимым, управляемым набором обязательств, а не сотнями или тысячами отдельных записей. Агрегация и консолидация данных в восходящем направлении до их синхронизации в Spiff уменьшает сложность как для представителей, так и для механизма комиссии. Конкретные методы управления синхронизацией данных в Spiff см. в разделе Оптимизация производительности фильтра данных в Salesforce Spiff.
- Понимание объемов данных в динамике. Конфигурация, обеспечивающая хорошую производительность при запуске, может ухудшаться по мере роста количества записей. Планируйте архивирование и просматривайте предполагаемые объемы вместе с рабочей группой по данным.
- Ограничьте поля страницы заявления нужными представителям. Каждое поле, выбранное на странице оператора, запускается механизмом для каждого оператора, вне зависимости от того, достигнет ли его путь вычисления. Удалите промежуточные вычисления и внутренние поля отслеживания из представления представителя.
- Включайте трассировку только там, где она служит цели. Trace сохраняет данные и потребляет память и время расчета. Включите его для полей, которые представители должны видеть в своих заявлениях или которые администраторы Comp обязательны для составления отчетов. Выключите его для промежуточных расчетов, прохождения взаимосвязей и любого поля, которое не нужно отображать в представлениях представителей или экспортах.
- Избегайте жестко запрограммированных значений. Храните переменные объемы в полях рабочих таблиц и используйте таблицы поиска, чтобы логика оставалась обслуживаемой при изменении бизнес-правил.
