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

  • Article

Les approches que vous utilisez pour garantir des performances optimales avec SharePoint sont différentes dans le nouveau modèle de complément SharePoint et dans le code de confiance totale. Dans un scénario ftC (Full Trust Code) /Solution de batterie de serveurs classique, 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 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 le code côté serveur et le code côté client. Dans le modèle de complément SharePoint, étant donné que le code est exécuté via les clients, un trafic réseau supplémentaire se produit. La réduction du nombre d’allers-retours d’appel d’API vers le serveur SharePoint augmente les performances de vos compléments SharePoint et réduit 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 les clients, il peut y avoir de longs délais avant la réception d’une réponse. La mise en cache des données pour des opérations de longue durée (comme les API de profil utilisateur) peut réduire le temps nécessaire pour retourner des informations ou recevoir la confirmation qu’un processus est terminé.

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 les techniques de mise en cache côté serveur et côté client pour stocker des informations.
  • Il n’est pas recommandé de stocker les ID client, les clientSecrets, les noms d’utilisateur, les mots de passe, les jetons ou d’autres informations de sécurité sensibles dans les caches.

Options pour garantir des performances optimales avec SharePoint

Vous disposez de deux options 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 en cache les données. 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 retournées par les appels d’API SharePoint dans les 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 4 095 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 d’expiration de données intégré. Toutefois, un tel mécanisme d’expiration peut être rapidement et facilement implémenté dans JavaScript.

      Pour obtenir un exemple, 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

Performance.Caching (exemple PnP O365) montre comment implémenter localStorage 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 côté serveur et de session, 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 retournées par les appels d’API SharePoint dans les 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 une session, des caches côté serveur stockés dans la RAM ou d’autres technologies de mise en cache tierces basées sur un 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 4 095 octets de données.

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

    Consultez 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 « man-in-the-middle »

Parfois, il est judicieux de créer votre propre couche de cache personnalisée. Un bon exemple est lorsque vous devez retourner des informations à partir du profil d’un utilisateur. L’exécution des API de profil utilisateur prend parfois beaucoup de temps. Pour fournir aux utilisateurs finaux une expérience d’interface utilisateur rapide, vous pouvez créer un travail de minuteur à distance pour interroger le service de profil utilisateur et stocker les informations dans diverses banques 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 la plupart fonctionnent très 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 SharePoint Office 365, 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 sharePoint managed code (Microsoft.SharePoint.Client.dll) et évaluer les données ou les 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’un travail web Azure, celles-ci ne doivent être lancées qu’une seule fois par période donnée, quel que soit le nombre de tentatives qu’un utilisateur tente de lancer une opération.
    • L’application de configurations de OneDrive Entreprise personnalisées est un bon exemple de ce scénario.

Prise en main

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 et fournit des liens vers plusieurs exemples et articles.

Exemples PnP

S’applique à

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