Ce que vous devez absolument savoir sur Reporting Services pour expliquer certains comportements au niveau de la performance …

Avez-vous déjà véçu une situation où la performance de Reporting Services était bonne puis tout d’un coup, un rapport prend presqu’une minute à s’exécuter?

C’est plus facile à observer en arrivant le matin. Le premier rapport, qui prend normalement moins de 10 secondes peut dépasser la minute?

Reporting Services fait la sieste et on le réveille ou quoi?

En fait l’explication est tout à fait rationnelle et il y a une solution pour mieux contrôler ce comportement.

Afin d’assurer une stabilité et une disponibilité 24/7, le processus ReportingServicesService.exe utilise plusieurs AppDomains pour implanter le Report Server Web Service, le Report Manager et les tâches pour le traitement en arrière plan.

L’autre raison d’utiliser des AppDomains est qu’une fois qu’un Dll .NET est chargé dans un AppDomain, il ne peut plus jamais être enlevé. Le Report Server permet en tout temps de remplacer un Dll dans son répertoire Bin et détecte lorsqu’on le fait. En créant / détruisant des AppDomains au besoin, il est en mesure de charger la nouvelle version du Dll pour les nouvelles requêtes.

Plutôt que d’exiger un redémarrage du service lors des événements suivants:

  1. Changement de la configuration de Report Server;
  2. Changement de la configuration ASP.Net pour les services Web du Report Server;
  3. Changement au niveau des Dlls du répertoire Program Files\Microsoft SQL Server\MSRS10.MSSQLSERVER\Reporting Services\ReportServer\bin;
  4. Échec d’allocation de mémoire.

Le Report Server effectue plutôt un recyclage de ses AppDomains. En gros, il garde l’ancien AppDomain pendant un certain temps (configurable) pour terminer les opérations en cours et redirige les nouvelles opérations vers le nouvel AppDomain.

Cette image ne représente pas tout à fait la vérité mais donne une idée de haut niveau de ce qui se passe:

image

Je viens de découvrir qu’il existe un outil pour voir les AppDomain d’un processus Windows:

image

On voit ci-haut que ReportingServicesService.exe a présentement 3 AppDomain: celui par défaut, un autre qui porte le nom de WindowsService_ suivi d’un numéro et finalement celui qui traite les requêtes au Report Server.

J’ai modifié le fichier rsreportserver.config afin d’observer la création / destruction d’AppDomain. On voit ci-bas qu’il commence par se créer un autre AppDomain pour WindowsServer_5.

image

Puis, il se crée un WindowsService_6 et détruit WindowsService_4, WindowsService_5 et celui pour le Report Server.

image

Ensuite il ne se passe plus rien. Afin qu’il recharge l’AppDomain du ReportServer, j’ai dû lancer un rapport et l’exécution de celui-ci a été plutot longue. On peut voir l’AppDomain nouvellement créé ici:

image

Alors voilà l’explication! Lors d’un recycle, l’AppDomain du Report Server n’est pas créé automatiquement. Lors de l’appel au premier rapport, il doit le créer, charger tous les Dlls du répertoire Bin, initialiser ses connexions vers ses bases de données etc.

Mais cela n’explique pas pourquoi une opération de recycle peut survenir en plein milieu de la journée même lorsque personne ne modifie la configuration. L’explication est que par défaut, le Report Server effectue un recycle à toutes les 12 heures. C’est configurable dans le fichier rsreportserver.config:

<Service>
  <RecycleTime>10080</RecycleTime>
  <MaxAppDomainUnloadTime>30</MaxAppDomainUnloadTime>

Ici j’ai mis 7 jours, 7 * 24 * 60 = 10080. L’autre paramètre permet de contrôler le nombre de minutes maximal pour terminer les requêtes actuelles dans l’ancien AppDomain.

C’est un peu navrant que l’on ne puisse pas plutôt spécifier une cédule pour le recyle (ex. tous les jours à 4h du matin) et qu’il n’y ait pas d’option pour forcer la création immédiate du AppDomain du Report Server.

Une solution pour pallier à ce problème est de:

  1. Forcer un arrêt et redémarrage du service pendant la nuit;
  2. Lancer un hyperlien vers le Report Server afin qu’il crée l’AppDomain;
  3. Mettre une valeur > 24 heures pour RecycleTime afin d’éviter que cela survienne pendant le jour.

Vous pouvez faire cela via un script Powershell:

$ssrs = « SQL Server Reporting Services (MSSQLSERVER) »
$rsurl = « 
http://localhost/ReportServer »
Stop-Service $ssrs
Start-Service $ssrs
$wc = New-Object system.net.webClient
$cred = [System.Net.CredentialCache]::DefaultNetworkCredentials
$wc.Credentials = $cred
$src = $wc.DownloadString($rsurl)

Et céduler cette tâche pendant la nuit.

De notre côté, on utilise plutôt notre outil de QA pour Reporting Services qui permet de lancer des jeux d’essai sur plusieurs Threads afin de non seulement réchauffer SSRS, mais aussi l’engin de cube (SSAS).

Références

Application Domains for Report Server Applications
http://msdn.microsoft.com/en-us/library/bb934330(v=sql.105).aspx

First report and report after specific time interval starts a long time on MS SQL 2008 Reporting Services
http://www.pawlowski.cz/2011/01/report-report-specific-time-interval-starts-long-time-ms-sql-2008-reporting-services/

Solving issue with first long starting report on SSRS 2008
http://www.pawlowski.cz/2011/07/solving-issue-long-starting-report-ssrs-2008/

AppDomain Viewer
http://labs.workshare.com/2010/08/app-domain-viewer.html#comment-form

Une réflexion sur “Ce que vous devez absolument savoir sur Reporting Services pour expliquer certains comportements au niveau de la performance …

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s