Freigeben über

Leistungsüberlegungen im SharePoint-Add-In-Modell

  • Artikel

Die Ansätze zum Sicherstellen der optimalen Leistung in SharePoint unterscheiden sich im neuen SharePoint-Add-In-Modell von der Vorgehensweise bei voll vertrauenswürdigem Code. In einem typischen Szenario mit voll vertrauenswürdigem Code (Full Trust Code, FTC)/einer Farmlösung erfolgten die meisten Codevorgänge im serverseitigen SharePoint-Objektmodellcode.

In einem SharePoint-Add-In-Modellszenario werden das clientseitige SharePoint-Objektmodell (Client-Side Object Model, CSOM) und/oder die SharePoint-REST-API zum Ausführen von Code verwendet.

Der Hauptunterschied zwischen den beiden Modellen ist serverseitiger Code im Vergleich zu clientseitigem Code. Im SharePoint-Add-In-Modell tritt zusätzlicher Netzwerkdatenverkehr auf, da Code über Clients ausgeführt wird. Die Minimierung der Anzahl von API-Aufruf-Roundtrips zum SharePoint-Server erhöht die Leistung Ihrer SharePoint-Add-Ins und reduziert die Menge der ressourcen, die von Ihrer SharePoint-Website verbraucht werden.

Darüber hinaus kann es im SharePoint-Add-In-Modell, da Code über Clients ausgeführt wird, zu langen Verzögerungen kommen, bevor eine Antwort empfangen wird. Das Zwischenspeichern von Daten für Vorgänge mit langer Ausführungsdauer (z. B. die Benutzerprofil-APIs) kann die Zeit reduzieren, die benötigt wird, um Informationen zurückzugeben oder eine Bestätigung zu erhalten, dass ein Prozess abgeschlossen ist.

Richtlinien auf hoher Ebene

Als Faustregel möchten wir die folgenden allgemeinen Richtlinien bereitstellen, um eine optimale Leistung mit SharePoint im neuen SharePoint-Add-In-Modell sicherzustellen.

  • Minimieren Sie clientseitige API-Aufrufe an den SharePoint-Server.
  • Verwenden Sie serverseitige und clientseitige Zwischenspeicherungstechniken, um Informationen zu speichern.
  • Es wird nicht empfohlen, clientIDs, clientSecrets, Benutzernamen, Kennwörter, Token oder andere vertrauliche Sicherheitsinformationen in Caches zu speichern.

Optionen zum Sicherstellen einer optimalen Leistung mit SharePoint

Sie haben eine Reihe von Optionen, um eine optimale Leistung mit SharePoint sicherzustellen.

  • Verwenden der clientseitigen Zwischenspeicherung
  • Verwenden der serverseitigen Zwischenspeicherung

Verwenden der clientseitigen Zwischenspeicherung

In diesem Muster werden clientseitige Zwischenspeicherungstechniken wie HTML5 LocalStorage und Cookies verwendet, um Daten zwischenzuspeichern. An diesen Speicherorten gespeicherte Informationen werden verwendet, um zu bestimmen, ob API-Aufrufe an einen SharePoint-Server erforderlich sind.

  • Dieses Muster speichert Von SharePoint-API-Aufrufen zurückgegebene Daten in clientseitigen Caches.
  • Dieses Muster verwendet clientseitigen Code (JavaScript), um Daten auszuwerten, die in clientseitigen Caches gespeichert sind.
  • Cookies sind auf die Speicherung von 4095 Bytes an Daten beschränkt.
    • Cookies verfügen über einen integrierten Datenablaufmechanismus.
  • HTML5 LocalStorage ist auf 5 MB Daten beschränkt.

    • HTML5 LocalStorage verfügt nicht über einen integrierten Datenablaufmechanismus. Ein solcher Ablaufmechanismus kann jedoch schnell und einfach in JavaScript implementiert werden.

      Ein Beispiel finden Sie unter den setLocalStorageKeyExpiry Funktionen und isLocalStorageExpired in der App.js JavaScript-Datei in Performance.LocalStorage (O365 PnP-Beispiel).

      Festlegen eines Ablaufschlüssels in 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
  {

    }
}

      Überprüfen Sie, ob der Ablaufschlüssel in LocalStorage abgelaufen ist:

      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;
  }
}

Wann ist die Option geeignet?

Wenn Sie die clientseitige Objektmodell-API (sp.js) von SharePoint ECMA verwenden und clientseitige Daten auswerten müssen, um festzustellen, ob die API-Aufrufe ausgeführt werden müssen.

Erste Schritte

Das Performance.Caching (O365 PnP-Beispiel) veranschaulicht, wie Sowohl LocalStorage als auch cookiebasiertes clientseitiges Zwischenspeichern im Add-In-Modell implementiert werden, und stellt Links zu mehreren Beispielen und Artikeln bereit.

Verwenden der serverseitigen Zwischenspeicherung

In diesem Muster werden serverseitige Zwischenspeicherungstechniken wie sitzungs- und serverseitige Cookieauswertung verwendet, um auf zwischengespeicherte Daten zuzugreifen. An diesen Speicherorten gespeicherte Informationen werden verwendet, um zu bestimmen, ob API-Aufrufe an einen SharePoint-Server erforderlich sind.

  • Dieses Muster speichert Daten, die von SharePoint-API-Aufrufen zurückgegeben werden, in serverseitigen Caches.

  • Dieses Muster verwendet serverseitigen Code zum Auswerten von Daten, die an serverseitigen Speicherorten gespeichert sind.

    • Serverseitige Speicherorte können sitzungsbasierte Daten, serverseitige Caches, die im RAM gespeichert sind, oder andere serverbasierte Cachetechnologien von Drittanbietern umfassen.

  • Dieses Muster verwendet serverseitigen Code, um in Cookies gespeicherte Daten auszuwerten.

  • Cookies sind auf die Speicherung von 4095 Bytes an Daten beschränkt.

    • Cookies verfügen über einen integrierten Datenablaufmechanismus.

    Weitere Informationen finden Sie unter der CookieCheckSkip-Methode in der Klasse Customizer.aspx.cs im OD4B. Configuration.Async (O365 PnP-Beispiel), um zu sehen, wie serverseitiger Code zum Auswerten von Cookies verwendet wird.

Implementieren einer eigenen Man-in-the-Middle-Cacheebene

Manchmal ist es sinnvoll, eine eigene benutzerdefinierte Cacheebene zu erstellen. Ein gutes Beispiel ist, wenn Sie Informationen aus dem Profil eines Benutzers zurückgeben müssen. Die Ausführung der Benutzerprofil-APIs dauert manchmal sehr lange. Um Endbenutzern eine schnelle Benutzeroberfläche zu bieten, können Sie einen Remote-Zeitgeberauftrag erstellen, um den Benutzerprofildienst abzufragen und die Informationen in einer Vielzahl von Datenspeichern zu speichern. Anschließend können Sie einen Dienst erstellen, mit dem Sie die Datenspeicher über JavaScript-Aufrufe von SharePoint-Add-Ins abfragen können.

Azure verfügt über viele verschiedene Speichermechanismen, die zum Speichern von Informationen verwendet werden können, von denen viele sehr schnell funktionieren, z. B. Table Storage und Blob Storage. Mit Azure können Sie auch eine Web-App erstellen, um den Dienst zu hosten und alle Daten und den Dienst mit demselben Azure Active Directory wie ein Office 365 SharePoint-Mandanten oder sogar eine lokale SharePoint-Umgebung mit aktiviertem DirSync zu schützen.

Wann ist die Option geeignet?

  • Wenn Sie die clientseitige Objektmodell-API (Microsoft.SharePoint.Client.dll) von SharePoint Managed Code verwenden und serverseitige Daten oder Cookies auswerten müssen, um festzustellen, ob die API-Aufrufe ausgeführt werden müssen.
  • Bei Vorgängen mit langer Ausführungsdauer, z. B. einem Azure-Webauftrag, sollte dieser nur einmal pro gegebenem Zeitrahmen initiiert werden, unabhängig davon, wie oft ein Benutzer versucht, einen Vorgang zu initiieren.
    • Das Anwenden von benutzerdefinierten OneDrive for Business Konfigurationen ist ein gutes Beispiel für ein solches Szenario.

Erste Schritte

Das Performance.Caching (O365 PnP-Beispiel) beschreibt, wie Sowohl LocalStorage als auch cookiebasiertes clientseitiges Zwischenspeichern im Add-In-Modell implementiert werden, und stellt Links zu mehreren Beispielen und Artikeln bereit.

PnP-Beispiele

Gilt für

  • Office 365 mit mehreren Mandanten (MT)
  • Office 365 dediziert (D)
  • SharePoint 2013 lokal