Расширенная функциональность
11
Янв
6

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

AllColumns

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

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

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

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

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

Отправляйте в БД запрос на обновление только измененных полей. Например, Вы делаете 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, если владелец фактически не изменился. Установка этого атрибута часто требует, каскадного изменения связанных объектов, соответственно увеличивая количество времени, требуемое для обработки данного изменения.

Комментарии (6)
  • Паша 11.01.2011

    Вопрос по ownerid — разве изменение ownerid через update метод возможно? Разве для этого не используется Assign сообщение?

  • slivka_83 11.01.2011

    Да, Вы правы 🙂 Был не внимателен 🙂

  • Паша 11.01.2011

    Невнимателен вроде слитно пишется. А по поводу неточности — может есть смысл подредактировать статью?

  • slivka_83 11.01.2011

    Да надо бы… 🙂 и времени надо бы… 🙂 и желания… а то знаете — лень ведь сильная штука 🙂 вообщем пошел править…
    * Тяжело вздыхает и идет править… 🙂 🙂 🙂

  • Азат 11.01.2011

    Даже не знаю, в который «Трактат…» следует писать.

    Недавно заметил: увеличение количества столбцов в представлениях значительно увеличивает время их загрузки, что в принципе логично :), но я не думал что настолько значительно 🙁
    Чтобы убедиться воочию, создайте кастомное представление (например, для контакта), добавьте в него все столбцы, опубликуйте, откройте контакты, выберите вновь созданное представление и ждите…
    Применительно к формам (например, тот же контакт): добавление всех полей на форму практически не увеличивает время загрузки формы 🙂

    Мораль такова: в представлениях есть смысл экономить на столбцах, в форме мало смысла экономить на полях

  • slivka_83 11.01.2011

    Добрый день 🙂

    >Чтобы убедиться воочию, создайте кастомное представление (например, для контакта), добавьте в него все столбцы, опубликуйте, откройте контакты, выберите вновь созданное представление и ждите…
    Ну, тут Вы явно переборщили 🙂 Все стобцы 🙂 Это слишком много, к тому же не имеет практического смысла 🙂 А если еще и выводить по 250 записей то вообще капец 🙂

    > в форме мало смысла экономить на полях
    До 5 ролапа это было не так: http://blogs.msdn.com/b/crm/archive/2009/07/22/microsoft-dynamics-crm-customized-entity-form-performance.aspx

*

code