Considérations relatives aux performances dans le modèle de complément SharePoint

Les approches que vous adoptez pour garantir des performances optimales avec SharePoint sont différentes dans le nouveau modèle de complément SharePoint de ce qu’elles étaient avec Full Trust Code. Dans un scénario classique de code de confiance totale (FTC) / de solution de batterie de serveurs, la plupart des opérations de code ont eu lieu dans le code du modèle objet côté serveur SharePoint .

Dans un scénario de modèle de complément SharePoint, le modèle d’objet côté client SharePoint (CSOM) et/ou l’API REST SharePoint sont utilisés pour exécuter du code.

La principale différence entre les deux modèles est la différence entre le code côté serveur et le code côté client. Dans le modèle de complément SharePoint, le code étant exécuté via des clients, un trafic réseau supplémentaire se produit. Le fait de réduire le nombre d’allers-retours d’appels d’API vers le serveur SharePoint permet d’augmenter les performances de vos compléments SharePoint et de réduire la quantité de ressources consommées par votre site SharePoint.

En outre, dans le modèle de complément SharePoint, étant donné que le code est exécuté via des clients, il peut y avoir de longs délais avant qu’une réponse ne soit reçue. La mise en cache des données pour les opérations de longue durée (comme les API de profil utilisateur) peut réduire le temps nécessaire au retour d’informations ou à la confirmation de la fin du processus.

Conseils généraux

En règle générale, nous aimerions fournir les instructions générales suivantes pour garantir des performances optimales avec SharePoint dans le nouveau modèle de complément SharePoint.

• Réduisez les appels d’API côté client au serveur SharePoint.
• Utilisez des techniques de mise en cache côté serveur et côté client pour stocker des informations.
• Il n’est pas recommandé de stocker des clientID, des secretsclient, des noms d’utilisateur, des mots de passe, des jetons ou d’autres informations de sécurité sensibles dans des caches.

Options pour garantir des performances optimales avec SharePoint

Plusieurs options s’offrent à vous pour garantir des performances optimales avec SharePoint.

• Utiliser la mise en cache côté client
• Utiliser la mise en cache côté serveur

Utiliser la mise en cache côté client

Dans ce modèle, les techniques de mise en cache côté client, telles que HTML5, LocalStorage et les cookies, sont utilisées pour mettre les données en cache. Les informations stockées dans ces emplacements sont utilisées pour déterminer s’il est nécessaire d’effectuer des appels d’API à un serveur SharePoint.

• Ce modèle stocke les données renvoyées à partir des appels d’API SharePoint dans des caches côté client.
• Ce modèle utilise du code côté client (JavaScript) pour évaluer les données stockées dans les caches côté client.
• Les cookies sont limités au stockage de 4095 octets de données.
  • Les cookies ont un mécanisme d’expiration des données intégré.
• HTML5 LocalStorage est limité à 5 Mo de données.

  • HTML5 LocalStorage n’a pas de mécanisme intégré d’expiration des données. Toutefois, un tel mécanisme d’expiration peut être rapidement et facilement implémenté dans JavaScript.

    Consultez les setLocalStorageKeyExpiry fonctions et isLocalStorageExpired dans le fichier JavaScriptApp.js dans Performance.LocalStorage (exemple PnP O365).

    Définition d’une clé d’expiration dans LocalStorage :

    function setLocalStorageKeyExpiry(key)
    {
        // Check for expiration config values
        var expiryConfig = localStorage.getItem(expiryConfigKey);
    
        // Check for existing expiration stamp
        var existingStamp = localStorage.getItem(key + expiryKeySuffix);
    
        // Override cached setting if a user has entered a value that is different than what is stored
        if (expiryConfig != null)
        {
            var currentTime = Math.floor((new Date().getTime()) / 1000);
            expiryConfig = parseInt(expiryConfig);
    
            var newStamp = Math.floor((currentTime + expiryConfig));
            localStorage.setItem(key + expiryKeySuffix, newStamp);
    
            // Log status to window
            cachingStatus += "\n" + "Setting expiration for the " + key + " key...";
            $('#status').val(cachingStatus);
        }
        else
      {
    
        }
    }
    

    Vérifiez si la clé d’expiration a expiré dans LocalStorage :

    function isLocalStorageExpired(key, keyTimeStampName)
    {
      // Retrieve the example setting for expiration in seconds
      var expiryConfig = localStorage.getItem(expiryConfigKey);
    
      // Retrieve the example setting for expiration in seconds
      var expiryStamp = localStorage.getItem(keyTimeStampName);
    
      if (expiryStamp != null && expiryConfig != null) {
    
          // Retrieve the expiration stamp and compare against specified settings to see if it is expired
          var currentTime = Math.floor((new Date().getTime()) / 1000);
    
          if (currentTime - parseInt(expiryStamp) > parseInt(expiryConfig)) {
              cachingStatus += "\n" + "The " + key + " key time stamp has expired...";
              $('#status').val(cachingStatus);
              return true;
          }
          else
          {
              var estimatedSeconds = parseInt(expiryStamp) - currentTime;
              cachingStatus += "\n" + "The " + key + " time stamp expires in " + estimatedSeconds + " seconds...";
              $('#status').val(cachingStatus);
              return false;
          }
      }
      else
      {
          //default
          return true;
      }
    }
    

Quand est-elle adaptée ?

Lorsque vous devez utiliser l’API de modèle objet côté client (sp.js) SharePoint ECMA et évaluer les données côté client pour déterminer si les appels d’API doivent être effectués.

Prise en main

La mise en cache Performance.Caching (exemple PnP O365) montre comment implémenter le stockage local et la mise en cache côté client basée sur les cookies dans le modèle de complément, et fournit des liens vers plusieurs exemples et articles.

Utiliser la mise en cache côté serveur

Dans ce modèle, les techniques de mise en cache côté serveur, telles que l’évaluation des cookies de session et côté serveur, sont utilisées pour accéder aux données mises en cache. Les informations stockées dans ces emplacements sont utilisées pour déterminer s’il est nécessaire d’effectuer des appels d’API à un serveur SharePoint.

• Ce modèle stocke les données renvoyées à partir des appels d’API SharePoint dans des caches côté serveur.

• Ce modèle utilise du code côté serveur pour évaluer les données stockées dans des emplacements côté serveur.

  • Les emplacements côté serveur peuvent inclure des données basées sur des sessions, des caches côté serveur stockés dans la mémoire RAM ou d’autres technologies tierces de mise en cache basées sur le serveur.

• Ce modèle utilise du code côté serveur pour évaluer les données stockées dans les cookies.

• Les cookies sont limités au stockage de 4095 octets de données.

  • Les cookies ont un mécanisme d’expiration des données intégré.

  Voir la méthode CookieCheckSkip dans la classe Customizer.aspx.cs dans l’OD4B . Configuration.Async (exemple PnP O365) pour voir comment le code côté serveur est utilisé pour évaluer les cookies.

Implémentation de votre propre couche de cache de l’intercepteur

Parfois, il est judicieux de créer votre propre couche de cache personnalisée. Par exemple, lorsque vous devez retourner des informations à partir du profil d’un utilisateur. L’exécution des API de profil utilisateur est parfois longue. Pour offrir aux utilisateurs finaux une expérience d’interface utilisateur rapide, vous pouvez créer une tâche de minuteur à distance pour interroger le service de profil utilisateur et stocker les informations dans divers magasins de données. Ensuite, vous pouvez créer un service pour vous permettre d’interroger les magasins de données via des appels JavaScript à partir de compléments SharePoint.

Azure dispose de nombreux mécanismes de stockage différents qui peuvent être utilisés pour stocker des informations, dont beaucoup fonctionnent extrêmement rapidement, comme le stockage Table et le stockage Blob. Azure vous permet également de créer une application web pour héberger le service et sécuriser toutes les données et le service avec le même Azure Active Directory qu’une location Office 365 SharePoint, ou même un environnement SharePoint local avec DirSync activé.

Quand est-elle adaptée ?

• Lorsque vous devez utiliser l’API de modèle objet côté client (Microsoft.SharePoint.Client.dll) de code géré par SharePoint et évaluer des données ou des cookies côté serveur pour déterminer si les appels d’API doivent être effectués.
• Lorsque vous avez des opérations de longue durée, telles qu’une tâche Web Azure, qui ne doivent être lancées qu’une seule fois par période donnée, quel que soit le nombre de tentatives d’exécution d’une opération par l’utilisateur.
  • L’application de configurations personnalisées de OneDrive Entreprise constitue un bon exemple d’un tel scénario.

Prise en main

La mise en cache Performance.Caching (exemple PnP O365) décrit comment implémenter LocalStorage et la mise en cache côté client basée sur les cookies dans le modèle de complément, ainsi que des liens vers plusieurs exemples et articles.

Liens associés

• Articles d’orientation dans https://aka.ms/OfficeDevPnPGuidance
• Références dans MSDN à https://aka.ms/OfficeDevPnPMSDN
• Vidéos dans https://aka.ms/OfficeDevPnPVideos

Exemples PnP

• Exemples et contenu sur Microsoft 365 Patterns and Practices (PnP)

S’applique à

• Office 365 multi-locataire (MT).
• Office 365 dédiés (D)
• SharePoint 2013 en local