Vous pouvez facilement identifier ce problème en vous posant les questions suivantes :

1. Votre pool d'applications se recycle-t-il fréquemment, surtout quand les charges sont élevées ?

   Ceci suppose que le pool d'applications est défini pour se recycler lorsqu'un seuil de mémoire est atteint. Le seuil de mémoire doit être compris entre 800 Mo et 1,5 Go (en supposant que vous avez au moins 2 Go de RAM). La définition du recyclage du pool d'applications à peu près à 1 Go donne les meilleurs résultats, mais vous devez effectuer des essais pour voir quels paramètres fonctionnent le mieux pour votre environnement. Si le paramètre de recyclage est trop bas, vous rencontrerez des problèmes de performances à cause du recyclage fréquent du pool d'applications. Si le paramètre est trop élevé, votre système commencera à présenter des problèmes de performances en raison de l'échange de pages, de la fragmentation de mémoire et d'autres problèmes.

2. Votre système fonctionne-t-il mal, surtout quand les charges sont élevées ?

   Lorsque l'utilisation de la mémoire commence à augmenter, le système doit compenser, par exemple, en paginant la mémoire et en gérant la fragmentation de mémoire.

3. Votre système se bloque-t-il ou les utilisateurs rencontrent-ils des erreurs inattendues comme des expirations de délais ou des erreurs de page indisponible, surtout quand les charges sont élevées ?

   En outre, lorsque l'utilisation de mémoire devient élevée ou fragmentée, certaines fonctions peuvent échouer parce qu'elles ne peuvent pas allouer de mémoire pour d'autres opérations. Dans bon nombre de cas, le code ne traite pas convenablement l'exception de « manque de mémoire », qui entraîne des erreurs fausses ou trompeuses.

4. Votre système utilise-t-il des composants WebPart personnalisés ou utilise des WebPart d'autres fournisseurs ?

   La plupart des développeurs WebPart ne sont pas conscients du fait qu'ils doivent supprimer les objets SharePoint et de la raison pour laquelle ils doivent le faire. Ils supposent que le nettoyage de la mémoire exécute cette fonction automatiquement, mais ce n'est pas vrai dans tous les cas.

Si vous répondez « oui » au numéro 4 et à au moins une des autres questions, il y a environ 90 pourcent de chances que votre code personnalisé ne supprime pas les éléments correctement. Comme vous pouvez le voir dans le Tableau 1, une seule page fortement utilisée qui ne supprime pas correctement les éléments suffit pour causer des problèmes. Voici un exemple de méthode pour réparer la fonction GetNavigationInfo précédente.

public void GetNavigationInfo()
{
   SPWeb oSPWeb = SPContext.Web;

   foreach(SPWeb oSubWeb in oSPWeb.GetSubWebsForCurrentUser()))
   {
      // .. Add subweb information for navigation ..
      oSubWeb.Dispose();
   }
}

Dans la boucle foreach, de nouveaux objets SPWeb sont créés chaque fois qu'ils sont récupérés de la collection. La plupart des développeurs supposent que ces objets sont nettoyés lorsqu'ils n'entrent plus dans l'étendue, mais ce n'est pas le cas quand vous utilisez le modèle d'objet SharePoint.

Vous devez être également conscient d'autres facteurs pouvant causer des problèmes. Par exemple, après avoir appelé la propriété RootWeb sur un site, vous devez supprimer l'objet SPWeb qu'elle crée en appelant la méthode RootWeb.Dispose(). Pour plus d'informations sur la façon de convenablement supprimer des éléments, reportez-vous à Méthodes recommandées : utilisation d'objets Windows SharePoint Services à supprimer.

Remarque :
Ne supprimez aucun élément retourné directement à partir de la propriété Microsoft.SharePoint.SPContext.Site ou Microsoft.SharePoint.SPContext.Web. Cela pourrait entraîner l'instabilité du système SharePoint et l'échec de l'application.

Les développeurs essaient d'augmenter les performances et l'utilisation de la mémoire en mettant en cache les objets SPListItemCollection qui sont retournés à partir des requêtes. C'est en général une bonne méthode mais l'objet SPListItemCollection contient un objet SPWeb intégré qui n'est pas « thread-safe » et ne doit pas être mis en cache. Par exemple, supposons que l'objet SPListItemCollection est mis en cache dans le thread A. Quand les autres threads essaient de le lire, l'application peut échouer ou peut se comporter étrangement parce que l'objet n'est pas « thread-safe ».

Pour plus d'informations, reportez-vous à la classe Microsoft.SharePoint.SPWeb.

Certains développeurs ne sont pas conscients du fait qu'ils opèrent dans un environnement multithreads (par défaut, les services Internet (IIS) sont multithreads) ou de la façon de gérer cet environnement. L'exemple de code suivant montre comment certains développeurs mettent en cache les objets Microsoft.SharePoint.SPListItemCollection.

public void CacheData()
{
   SPListItemCollection oListItems;

   oListItems = (SPListItemCollection)Cache["ListItemCacheName"];
   if(oListItems == null)
   {
      oListItems = DoQueryToReturnItems();
      Cache.Add("ListItemCacheName", oListItems, ..);
   }
}

Dans l'exemple de code précédent, le problème est que si la requête d'obtention des données dure 10 secondes, beaucoup d'utilisateurs peuvent accéder à cette page en même temps et tous exécuter la même requête et essayer de mettre à jour le même objet de cache au même moment. Ceci peut engendrer des problèmes de performances car la même requête pourrait être exécutée 10, 50 ou 100 fois et ceci peut provoquer des incidents parce que plusieurs threads essaient de mettre à jour le même objet au même moment, surtout sur les ordinateurs multiprocessus et avec hyperthreading. Pour résoudre ce problème, vous devez modifier le code comme suit.

public void CacheData()
{
   SPListItemCollection oListItems;

   lock(this)   {
      oListItems = (SPListItemCollection)Cache["ListItemCacheName"];
      if(oListItems == null)
      {
         oListItems = DoQueryToReturnItems();
         Cache.Add("ListItemCacheName", oListItems, ..);
     }
   }
}

Remarque :

Il est possible d'augmenter légèrement les performances en plaçant le verrou dans le bloc de code if(oListItems == null). Dans ce cas, vous n'avez pas besoin d'interrompre tous les threads pendant que vous vérifiez si les données sont déjà mises en cache. Selon le temps que prend la requête pour retourner les données, il reste toujours possible que plusieurs utilisateurs exécutent la requête au même moment. C'est surtout vrai si vous utilisez des ordinateurs multiprocesseur. N'oubliez pas que le nombre de processeurs en fonctionnement est élevé, plus la requête a besoin de temps pour s'exécuter, et plus il est probable que le placement du verrou dans le bloc de code if() causera des problèmes. Bien que l'exemple précédent puisse causer une légère baisse de performances, c'est le seul moyen de garantir que plusieurs requêtes ne s'exécuteront pas au même moment.

Ce code interrompt tous les autres threads dans une section critique s'exécutant dans Internet Information Services et empêche les autres threads d'accéder à l'objet mis en cache jusqu'à ce qu'il soit généré complètement.

L'exemple précédent adresse le problème de synchronisation de thread ; cependant, il n'est toujours pas optimal parce qu'il met en cache un objet qui n'est pas « thread-safe ». Pour assurer la sûreté des threads, vous mettez en cache un objet DataTable qui est créé à partir de l'objet SPListItemCollection. Par exemple, vous modifiez l'exemple précédent comme suit.

public void CacheData()
{
   DataTable oDataTable;
   SPListItemCollection oListItems;

   lock(this)
   {
      oDataTable = (DataTable)Cache["ListItemCacheName"];
      if(oDataTable == null)
      {
         oListItems = DoQueryToReturnItems();
         oDataTable = oListItems.GetDataTable();
         Cache.Add("ListItemCacheName", oDataTable, ..);
      }
   }
}

Votre code obtient alors les données de l'objet DataTable. Pour plus d'informations et d'exemples d'utilisation de l'objet DataTable et d'autres bonnes idées pour développer des applications SharePoint, consultez les trucs et astuces pour le développement avec Windows SharePoint Services.

Vous mettez en cache vos données en utilisant l'objet System.Web.Caching.Cache. Cet objet nécessite que vous interrogiez les données une fois et que vous les enregistriez dans le cache pour que les autres utilisateurs puissent y accéder.

Si vos données sont statiques, vous pouvez configurer le cache de manière à charger les données et ne pas expirer une avant le redémarrage de l'application ou charger une fois par jour pour garantir l'actualisation des données. Vous pouvez créer l'élément de cache lorsque l'application démarre, lorsque la première session utilisateur démarre ou lorsque le premier utilisateur essaie d'accéder aux données.

Si vos données sont plutôt statiques, vous pouvez configurer les éléments du cache de manière à expirer dans un certain nombre de secondes, de minutes ou d'heures après leur création. Ceci vous permet d'actualiser vos données selon un horaire acceptable pour vos utilisateurs. Même si les données ne sont mises en cache que 30 secondes, quand les charges sont élevées vous verrez toujours une hausse des performances car vous exécutez le code seulement une fois toutes les 30 secondes et non plusieurs fois par seconde, pour chaque utilisateur qui accède au système.

Assurez-vous de prendre en considération les problèmes présentés précédemment dans Mise en cache des données et des objets.

Réfléchissez à la façon dont vos données seront utilisées. Si ces données sont utilisées pour prendre des décisions d'exécution, les placer dans un objet DataSet ou DataTable peut être la meilleure méthode pour les stocker. Vous pouvez ensuite interroger ces objets pour les données pour prendre des décisions d'exécution. Si les données sont utilisées pour afficher une liste, un tableau ou une mise en page à l'utilisateur, envisagez de générer un objet d'affichage et de l'enregistrer dans le cache. Au moment de l'exécution, il vous suffit de récupérer l'objet à partir du cache et d'appeler sa fonction de rendu pour afficher son contenu. Vous pouvez également enregistrer la sortie affichée, mais ceci peut poser des problèmes de sécurité et l'élément mis en cache peut être relativement volumineux, ce qui entraîne un échange de pages important ou une fragmentation de mémoire.

Selon la configuration de votre site SharePoint, vous pouvez devoir résoudre différemment certains problèmes de mise en cache. Si vos données doivent constamment être identiques sur tous les serveurs, vous devez vous assurer que les mêmes données sont mises en cache sur chaque serveur. Une méthode pour garantir ceci consiste à créer les données de cache et de les enregistrer sur un serveur commun ou dans une base de données SQL. Une fois encore, vous devez prendre en compte le temps nécessaire pour accéder aux données et les problèmes de sécurité posés si les données sont enregistrées sur un serveur commun.

Vous pouvez créer également des objets de couche d'entreprise qui mettent en cache les données sur un serveur commun, puis accéder à ces données par différentes communications interprocessus disponibles dans les objets de réseau ou les API.

Nous aimerions remercier les personnes suivantes pour l'aide fantastique qu'ils ont apportée pour les révisions techniques de cet article : James Waymire (Microsoft Corporation), Duray Akar (Microsoft Corporation), Rashid Aga (Microsoft Corporation), Roger Lamb (Microsoft Corporation) et Jeff Lin (Microsoft Corporation).