Практическое руководство. Повышение производительности решения Business Connectivity Services при использовании кэша

Статья
09/18/2014

Дата последнего изменения: 30 июня 2010 г.

Применимо к: SharePoint Server 2010

В этой статье
Использование поля версии для сведения к минимуму обращений к внешнему источнику данных
Включение связей только при крайней необходимости
Использование двух подписок вместо одной при необходимости в связанных данных
Задание элементов для синхронизации с помощью явных идентификаторов в подписке
Задание фильтров для сокращения объема данных, загружаемых клиентским приложением
Пример

При проектировании решения Business Connectivity Services, в котором будет использоваться кэш, следует иметь в виду следующие рекомендации для наиболее эффективного использования кэша и обеспечения оптимальной производительности приложения.

Используйте поле версии (если доступно) для сведения к минимуму обращений к внешнему приложению.
Включайте связи, только если они необходимы приложению, и убедитесь, что пользователи не смогут включать связи случайно.
При необходимости в связанных данных старайтесь использовать две подписки вместо одной подписки со связью.
Указывайте элементы для синхронизации с помощью явных идентификаторов в подписке.
Задавайте фильтры для сокращения объема данных, загружаемых клиентским приложением.

Рассмотрим указанные выше рекомендации подробно.

Использование поля версии для сведения к минимуму обращений к внешнему источнику данных

С помощью поля версии во внешнем источнике данных можно серьезно уменьшить число обращений к внешнему источнику данных. Поле версии может быть полем с увеличивающимся значением, которое обозначает версию экземпляра сущности, или штампом времени LastModified, который указывает время последнего обновления экземпляра сущности во внешнем источнике данных. Если такое поле доступно, оно должно быть частью возвращаемого параметра методов Finder и SpecificFinder в модели. Если поле версии доступно, то процесс синхронизации получает идентификатор и версию из внешнего приложения и вызывает метод SpecificFinder, только если версия отличается от находящейся в кэше.

Включение связей только при крайней необходимости

Если подписка содержит включенные связи, то процесс синхронизации наполняет кэш экземплярами связанных сущностей. Для этого он делает столько вызовов экземпляра метода Associate, сколько для этой подписки существует экземпляров сущности в кэше. В результате возвращаются идентификаторы экземпляры связанных сущностей. Затем процесс вызывает метод SpecificFinder для каждого из возвращенных идентификаторов для выборки остальных полей. Поэтому включать связи следует только в случае крайней необходимости, поскольку они накладывают значительную дополнительную нагрузку на кэш и могут серьезно повлиять на производительность приложения.

Использование двух подписок вместо одной при необходимости в связанных данных

Как говорилось выше, связи оказывают значительную дополнительную нагрузку на кэш и могут оказывать серьезное влияние на производительность приложения. Если в приложении нужны связанные данные, подумайте о создании двух подписок: одной для клиентов и другой для заказов, вместо использования связей подписок. Это приведет к снижению числа вызовов внешнего приложения и повышению производительности приложения.

Задание элементов для синхронизации с помощью явных идентификаторов в подписке

Если точно известно, какие элементы нужно синхронизировать, можно просто добавить их идентификаторы к подписки по отдельности. Это намного проще сделать программным способом, потому что сериализованный идентификатор необходимо поместить в XML-файле подписки.

Чтобы получить сериализованный идентификатор, создайте экземпляр объекта Identity с соответствующими значениями идентификатора и вызовите его метод Serialize. Дополнительные сведения см. в описании метода Identity.Serialize().

Получив сериализованную строку идентификатора, ее можно добавить в тег <Identity> внутри тега <Identities>, как показано в примере в данном разделе ниже (см. Пример.)

Задание фильтров для сокращения объема данных, загружаемых клиентским приложением

Очевидным способом оптимизировать процесс синхронизации является сокращение объема данных, загружаемых клиентом, и добиться этого проще всего с помощью фильтров. В инфраструктуре синхронизации поддерживаются фильтры Wildcard, Comparison и Limit, которые можно использовать для сокращения числа загружаемых элементов. Например, с помощью фильтра Wildcard можно загрузить анкеты всех сотрудников, имена которых начинаются на букву "M", указав в качестве значения фильтра "M*". Либо можно выбрать всех клиентов с почтовым индексом "98052" с помощью фильтра сравнения. С помощью фильтра Limit можно ограничить число продуктов цифрой 100.

Пример

Ниже приводится пример подписки, явные идентификаторы которой больше 11003 и 11020, и фильтра, который возвращает только клиентов с идентификаторами CustumerID больше 11050.

<?xml version="1.0" encoding="utf-8"?> 
<Subscription LobSystemInstanceName="AdventureWorksContosoLOBInstance" 
    EntityNamespace="AdventureWorksContoso" EntityName="Customer" 
    Name="AdventureWorksContosoCustomerSubscription" View="GetCustomerById" 
    IsCached="true" RefreshIntervalInMinutes="360" 
    xmlns="https://schemas.microsoft.com/office/2006/03/BusinessDataCatalog"> 
  <Identities> 
    <Identity>i+yoAAA==</Identity> 
    <Identity>iDCsAAA==</Identity> 
  </Identities> 
  <Queries> 
    <Query Name="AdventureWorksContosoCustomerQuery" 
        MethodInstanceName="GetCustomers" 
        DefaultDisplayName="Customer Read List" 
        RefreshIntervalInMinutes="180" IsCached="true" Enabled="true"> 
      <FilterValues> 
        <FilterValue FilterDescriptorName="MinCustomerId" FilterIndex="0" 
            Type="System.Int32">11050</FilterValue> 
      </FilterValues> 
    </Query> 
  </Queries> 
</Subscription>

Примечание
Ниже указанные некоторые важные замечания. Фильтры, используемые в файле подписки, необходимо определить в модели подключения к бизнес-данным, и их должна поддерживать внешняя система. Кроме того, при обновлении существующей модели подключения к бизнес-данным вручную необходимо увеличить номер версии внешнего типа контента, который был изменен, чтобы гарантировать, что внесенные изменения будут учтены во время развертывания.

Ниже указанные некоторые важные замечания.

Фильтры, используемые в файле подписки, необходимо определить в модели подключения к бизнес-данным, и их должна поддерживать внешняя система.
Кроме того, при обновлении существующей модели подключения к бизнес-данным вручную необходимо увеличить номер версии внешнего типа контента, который был изменен, чтобы гарантировать, что внесенные изменения будут учтены во время развертывания.

Поделиться через