Оптимизация производительности SharePoint

в 8:38, , рубрики: sharepoint, sharepoint 2010, sql, sql server 2008 r2, windows server 2008 r2, Администрирование баз данных

Введение

Три года назад мы начали использовать SharePoint Foundation 2010 SP2 в качестве системы электронного документооборота и контроля различных бизнес процессов. Как обычно бывает в начале все «летало». Первоначально, в первый год, развернул его на обычной машине (не серверные компоненты), назовем его условно SRV1, где вместе с ним крутился Active Directory, файл-сервер, шлюз интернета, DNS и DHCP. Характеристики SRV1:

  1. Процессор — Intel® Core(TM) i5-2500 CPU @ 3.30GHz
  2. Память — 8 Гб
  3. Материнская плата — Gigabyte GA-Z68P-DS3 (2 PCI, 2 PCI-E x1, 2 PCI-E x16, 1 mSATA, 4 DDR3 DIMM, Audio, Video, Gigabit LAN)
  4. Винчестер — 2 Wetern Digital Caviar Blue 500 Гб RAID-1.
  5. Сеть — Realtek RTL8168/8111 PCI-E Gigabit Ethernet Adapter PCI

Через год, мной было принято решение разграничить полномочия серверов и была куплена серверная стойка и блейд-сервер, собранный на серверных компонентах Intel, конкретно под нужды SharePoint, назовем его условно SRV2. Характеристики SRV2:

  1. Процессор — QuadCore Intel Xeon E3-1240 v2, 3400 MHz (34 x 100)
  2. Память — 32 Гб
  3. Материнская плата — Intel Beartooth Pass LC S1200BTL (1 PCI, 1 PCI-E x1, 3 PCI-E x8, 1 PCI-E x16, 4 DDR3 DIMM, Video, Dual LAN)
  4. Винчестер — 2 Western Digital RE4 1TB RAID-1
  5. Сеть — Intel® 82579LM Gigabit Network Connection

С этого момента прошел еще год и пользователи активно генерировали данные, программист накодил около дюжины кастомных решений для наших потребностей и нужд. Мне тогда показалось, что — все, ближайшие 2-3 года можно не беспокоиться о производительности SharePoint.

Немного контекста

В SharePoint у нас есть список «Задачи», в котором хранятся задачи для каждого сотрудника. У задачи может быть от 0 до ∞ исполнителей. Задачи есть «большие» и «маленькие», т.е. скажем у сотрудника(ов) висит бессрочная задача, у этой задачи история (журнал версий) с длиной в год, в моем случае — это примерно 2500 комментариев к задаче. У маленьких задач, соответственно, раз в пять короче.

Выявление узкого места

Первым делом включаем Панель разработчика в Sharepoint. Штука очень полезная и очень информативная. Запускаем Командную консоль SharePoint от имени администратора и наберем в ней следующее:

 stsadm -o setproperty -pn developer-dashboard -pv on

Далее возвращаемся в браузер и обновляем страницу с задачей. Внизу страницы Вы увидите вывод панели разработчика. Нас интересует раздел Запросы баз данных. В частности у меня, в последней строке (см. скриншот ниже), по некоторым «большим» задачам в последней строке были значения около 150000 мс = 2.5 мин. Отсюда делаем вывод, что проблема в БД.
Оптимизация производительности SharePoint - 1
Если вы нажмете на последнюю строку, если запрос слишком длинный, то целиком вы его не увидите. А запрос нам нужен целиком, чтобы посмотреть где он «спотыкается» и вытаскивает 2500 строк больше двух минут.
Второе. Отключаем всех пользователей от SharePoint. Далее запускаем SQL Server Profiler. Нажимаем File — New Trace. В открывшемся диалоговом окне на вкладе General выставляем значение параметра Use the template, выбираем Standart(default). В браузере идем на целевую страничку с задачей, которая тормозит и давим F5. Далее идем в SQL профайлер в колонке TextData ищем строки начинающиеся с exec sp_executesql 'N ..., а уже в них среди них ищем конкретно наш запрос. Итак, на этой стадии мы подошли непосредственно к оптимизации.

Оптимизация

Открываем SQL Server Managment Studio. Жмем New Query. Вставляем целевой запрос найденный при помощи SQL Profiler. На панели инструментов жмем Include Actual Execution Plan.
Оптимизация производительности SharePoint - 2
Далее выполняем запрос, т.е. жмем Execute. После выполнения запрос, на вкладе Execution Plan я увидел следующее:
Оптимизация производительности SharePoint - 3
Если нажмем на вкладке Execution Plan на текст выделенный на скриншоте красным правой кнопкой мыши, далее выберем Missing Indexes Details… Откроется окно с закомментированным SQL запросом для создания индексов на нужные колонки:

/*
Missing Index Details from slow.sqlplan
The Query Processor estimates that implementing the following index could improve the query cost by 35.2777%.
*/

/*
USE [WSS_Content]
GO
CREATE NONCLUSTERED INDEX [<Name of Missing Index, sysname,>]
ON [dbo].[AllUserData] ([tp_ID],[tp_ListId],[tp_SiteId],[tp_RowOrdinal],[tp_DeleteTransactionId],[tp_Level],[tp_IsCurrentVersion])

GO
*/

По умолчанию, SQL Management предлагает создать один индекс на все колонки. Мы сделаем иначе, вооружившись практикой и логикой, мы создадим на каждую колонку в таблице AllUserData свой индекс, потому что данные колонки очень активно используется при работе с списками в SharePoint.

USE [WSS_Content]
GO
create nonclustered index AllUserData_tpID on dbo.AllUserData (	tp_ID ASC )
create nonclustered index AllUserData_tp_ListId on dbo.AllUserData ([tp_ListId] ASC);
create nonclustered index AllUserData_tp_SiteId on dbo.AllUserData ([tp_SiteId] ASC);
create nonclustered index AllUserData_tp_RowOrdinal on dbo.AllUserData ([tp_RowOrdinal] ASC);
create nonclustered index AllUserData_tp_DeleteTransactionId on dbo.AllUserData ([tp_DeleteTransactionId] ASC);
create nonclustered index AllUserData_tp_Level on dbo.AllUserData ([tp_Level] ASC);
create nonclustered index AllUserData_tp_IsCurrentVersion on dbo.AllUserData ([tp_IsCurrentVersion] ASC );
GO

На этом все. Небольшие изыскания описанные в статье позволяют добиться скорости запроса вместо 150000 мс в 1468.05 мс, что вы можете сами посчитать, дает прирост в производительности почти в 100 раз.

P/S/ Спасибо за время.
P/P/S Вопрос оставшийся без ответа: почему в SharePoint индексы на эти колонки не добавлены по умолчанию?

Автор: houk

Источник


* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js