Нагрузочное тестирование Sharepoint 2010

Исходные данные: Sharepoint 2010 портал, 3000 активных пользователей, база контента около 100 Гб. Железо: 2 WFE, 1 SQL.
Проблема: перед внедрением очередного сайта (а вместе с ним изрядного количества пользователей) проводили нагрузочное тестирование по добавлению большого количества контента на сайт.
Было написано консольное приложение, добавляющее рандомно генерируемые элементы в списки. В три разные списка добавлялись элементы общей численностью чуть более полумиллиона.
Нужно отметить, что проблемы начались сразу после запуска приложения. Периодическое зависание сайта на 10-15секунд, благо запускали перед выходными, и это было не критично. Возникающие фризы списали на работу самой процедуры добавления.
После завершения добавления записей проблема не исчезла. Причем зависание фиксировалось уже на всем семействе сайтов. В течение двух суток пытались определить причины задержек и устранить их. В этот период впервые были зафиксированы пики нагрузки по IO на SQL-сервере.

Причем периодически возникновение пиков (в основном операция чтения 60-100 Мб/сек. на базе с контентом) вызывало рост очереди заданий SQL-сервера. Но не всегда.
Было принято решение об удалении тестового контента. В течении двух последующих суток, ночами, запускалось приложение удаления элементов (как оказалось удалять дольше).
Проблема осталась.
Путем анализа самых дорогих запросов был выявлен SQL-запрос, вызывающий пики, который является частью хранимой процедуры proc_GetChanges базы данных контента.

SELECT TOP (@MaxChanges)
 EventTime,
 Id,
 CASE 
  WHEN (ObjectType = 2048 AND @SiteId IS NOT NULL) 
   THEN @SiteId 
  ELSE 
   SiteId 
 END AS SiteId,
 WebId,
 ListId,
 ItemId,
 DocId,
 Guid0,
 Int0,
 ContentTypeId,
 ItemFullUrl,
 EventType,
 ObjectType,
 TimeLastModified,
 Int1,
 DocClientId
FROM
 TVF_EventCache_GTIdLEQId(@ChangeNumber, @ChangeNumberEnd) AS EC
WHERE
 (EventType & @EventTypeMask) != 0 AND
 (ObjectType & @ObjectTypeMask) != 0
ORDER BY 
 Id ASC

Функция TVF_EventCache_GTIdLEQId обращается к таблице EventCache, которая хранит список всех изменений всех элементов. Таблица, содержала 7,5 миллионов записей, а указанная выборка происходила без учета @SiteId. Исходя из описания данная таблица содержит факты изменения всех элементов для осуществления рассылок. У нас стояла настройка для хранения изменений за 60 дней.

Как оказалось пагубными в нашем случае оказалась совокупность этой настройки и проведенное тестирование с добавлением и последующим удалением элементов.
Решение: изменить настройку на хранение элементов за 7 дней. Настройка располагается здесь: Центр администрирования -> Управление веб-приложениями -> Общие параметры -> Регулирование ресурсов -> Журнал изменений