Трактат о производительности MS CRM. Книга IV: разработка…

AllColumns

Никогда не возвращайте все поля из веб-службы. Даже стандартные объекты CRM содержат больше 20 полей. Это занимает (относительно) много времени, чтобы вытащить их из БД и вернуть в Ваш плагин (например). Поэтому возвращайте только поля, которые Вам необходимы для работы. Для этого используйте ColumnSet.

При использовании методов, которые возвращают данные с сервера, запрашивайте минимальное количество данных, необходимых Вашему приложению.
Для метода Retrieve это параметр ColumnSet, чтобы определить атрибуты, которых необходимо вернуть.

При использовании метода RetrieveMultiple определите необходимые атрибуты используя QueryBase.ColumnSet.

При использовании любого сообщения, которое использует QueryExpression, используйте свойство QueryBase.ColumnSet чтобы определить критерии запроса. Следующие сообщения содержат QueryExpression:

• RetrieveByGroupResource
• RetrieveByResourceResourceGroup
• RetrieveByResourcesService
• RetrieveMultiple
• RetrieveParentGroupsResourceGroup
• RetrieveSubGroupsResourceGroup
• Rollup

Обновляйте только измененные поля

Отправляйте в БД запрос на обновление только измененных полей. Например, Вы делаете retrievemultiple, и возврайщете 20 полей. Затем Вы обновляете одно поле CrmBoolean и вызываете service.Update. Это действие обновит все 20 полей в БД теми же самыми значениями (кроме одного). Это в результате это плохо сказывается на производительности.
Чтобы добиться этого можно держать отдельно поля, которые Вы хотите обновить. Например, создайте вспомогательную функцию, которая возвращает DynamicEntity и его ключевое поле. После чего Вы можете добавить к нему необходимые свойства со значениями и отправить их в веб-службу на обновление.

internal static DynamicEntity GetBlankEntity(string entityName, string primaryKeyAttribute, Guid id)
{
	DynamicEntity entity = new DynamicEntity(entityName);
	entity.Properties[primaryKeyAttribute] = new Key(id);
	return entity;
}

DynamicEntity entity = CRMUtilities.GetBlankEntity("new_job", "new_jobid", id);
entity.Properties["new_jobcompleted"] = new CrmBoolean(true);
service.Update(entity);

Pre-Event forever

Pre-плагины происходят прежде, чем изменения будут сохранены в базу данных. Преимущество использования Pre-плагинов, особенно при Создании и Обновлении, состоит в том, что Вы не должны обновить базу данных дважды. Вы можете изменить поля, которые поступают на вход плагина или дополнить его новыми полями перед передачей в веб-службу для сохранения.

Асинхронные плагины или кастомные Бизнес-процессы для долго выполняющихся процессов

Пока синхронные плагины выполняются, пользователям приходится ждать завершения их работы. Если у Вас есть процесс, который выполняется больше пары секунд, рассмотреть асинхронное выполнение Вашего кода. Это может быть сделано с использованием асинхронных плагинов или кастомных Бизнес-процессов.

Длинный-длинный Бизнес-процесс

С точки зрения производительности лучше создать один длинный Бизнес-процесс, чем много дочерних Бизнес-процессов и вызвать их из родительского Бизнес-процесса. Хотя при этом и усложняется его поддерживаемость… И не стоит беспокоиться об издержках компиляции, потому что Бизнес-процесс компилируется во время публикации. Однако, есть издержки про запуске каждого экземпляра Бизнес-процесса. Потому что это требует возвращения всех объектов, используемых в Бизнес-процессе, а также запуск каждого дочернего Бизнес-процесса происходит в 2 шага: создание системной записи «Workflow Expansion Task» и собственно самого экземпляр дочернего Бизнес-процесса. Поэтому для максимальной производительности лучше использовать один длинный Бизнес-процесс.

Общие методы

Общие методы CrmService выполняются быстрее чем метод CrmService.Execute с соответствующим сообщением. Следующая таблица приводит эти методы и сообщения:

Method	Message
Create Method	Create Message
Delete Method	Delete Message
Update Method	Update Message
Retrieve Method	Retrieve Message
RetrieveMultiple Method	RetrieveMultiple Message

Strong Types

Класс DynamicEntity полезен, когда Ваш код должен работать над объектами и атрибутами, которые не известны во время его написания и компиляции. Однако эта гибкость имеет и свою цену использования, выражающуюся в производительности. Если Ваши объекты уже определены во время написания кода, Вы должны использовать strong types, которые сможете получить используя WSDL.

Ownerid

Не изменяйте атрибут ownerid, если владелец фактически не изменился. Установка этого атрибута часто требует, каскадного изменения связанных объектов, соответственно увеличивая количество времени, требуемое для обработки данного изменения.