SSRS в режиме SharePoint. Деградация производительности. Объяснение и предложения.

Мы обнаружили значительное ухудшение производительности служб Reporting Services при использовании действий Go To Report в режиме SharePoint.

В принципе, после нескольких действий «Перейти к отчету» цена, выплачиваемая за сохранение всех предыдущих исполнений, становится выше, чем время, затрачиваемое на рендеринг текущего отчета.

Каждый раз, когда пользователь нажимает на действие «Перейти к отчету», генерируется новый идентификатор выполнения, добавляется в состояние «Просмотр», а строка вставляется в SessionData (база данных TempDB). Эта строка истекает через заданное время (по умолчанию = 10 минут). Когда сессия истекла, строка будет очищена.

Существует два механизма для предотвращения истечения всех предыдущих исполнений:

• Каждый раз, когда пользователь использует действие «Перейти к отчету», все предыдущие исполнения отчета «коснутся», чтобы не допустить их истечения. Это означает, что в нескольких строках таблицы SessionData будет обновлен столбец Expiration. Это добавляет значительное количество времени на рендеринг отчета (это не делается в фоновом потоке …)

• Существует постоянный HTTP-запрос, который выполняется автоматически, если пользователь оставляет свой браузер открытым в отчете SSRS без взаимодействия с ним. Это также «коснется» всех предыдущих отчетов, чтобы предотвратить их истечение.

Все это было сделано, чтобы пользователь мог использовать кнопку панели инструментов SSRS. При обратном вызове на сервере появляется событие с идентификатором выполнения. Сервер может извлекать всю информацию о предыдущем выполнении (например, отчет, значения параметров) из таблицы SessionData и эффективно предоставлять отчет.

По нашему опыту, пользователи никогда не вернутся более чем в 2-3 раза, используя обратно. В настоящее время нет возможности ограничить длину истории (количество раз, которое пользователь может использовать обратно), чтобы лучше сбалансировать гибкость пользователя и производительность.

Таким образом, история продолжает расти вечно (особенно, если Go to report используется как навигация между отчетами). По мере роста производительность снижается настолько, что пользователям лучше закрыть окно браузера и начать снова.

Вы когда-нибудь замечали это поведение? Это не происходит с действиями Go To Url.

Microsoft теперь знает об этой проблеме, но может рассмотреть только способ ее устранения для следующей версии (2016), что не очень практично. Вы можете помочь в голосовании по этим трем записям connect.microsoft.com, потому что они много используют для определения приоритетов:

Конфигурируемое значение количества выполненных отчетов для хранения в истории (для обратной цели)
Использовать HTTP POST для действий Go To Url
Простота воспроизведения, значительное снижение производительности SSRS при использовании действий Go To Report