Considérations sur les performances dans le modèle SharePoint de développement
Les approches que vous prenez pour garantir des performances optimales avec SharePoint sont différentes dans le nouveau modèle de SharePoint par rapport au code de confiance totale. Dans un scénario classique de code de confiance totale /solution de batterie de serveurs, la plupart des opérations de code ont eu lieu dans le code SharePoint modèle objet côté serveur.
Dans un SharePoint de modèle de 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 SharePoint complément, étant donné que le code est exécuté via des clients, un trafic réseau supplémentaire se produit. Réduire le nombre d’allers-retours d’appel d’API vers le serveur SharePoint augmente les performances de vos SharePoint et réduit la quantité de ressources consommées par votre site SharePoint.
En outre, dans le modèle SharePoint complément, étant donné que le code est exécuté via les clients, il peut y avoir de longs retards avant la réception d’une réponse. La mise en cache des données pour les opérations de longue durée (telles que les API de profil utilisateur) peut réduire le temps qu’il faut pour retourner des informations ou recevoir la confirmation qu’un processus est terminé.
Conseils généraux
En règle générale, nous voulons fournir les instructions générales suivantes pour garantir des performances optimales avec SharePoint dans le nouveau modèle de SharePoint de développement.
- Réduisez les appels d’API côté client SharePoint serveur.
- 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 identifiants client, 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 avez plusieurs 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 à ces emplacements sont utilisées pour déterminer s’il est nécessaire d’effectuer des appels d’API à un SharePoint serveur.
- Ce modèle stocke les données renvoyées par SharePoint appels d’API 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 ne comprend pas de mécanisme d’expiration des données intégré. Toutefois, un tel mécanisme d’expiration peut être rapidement et facilement implémenté dans JavaScript.
Consultez les fonctions du fichier
setLocalStorageKeyExpiryisLocalStorageExpiredJavaScriptApp.js dans l’exemple Performance.LocalStorage (O365 PnP) pour obtenir un exemple.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 SharePoint ECMA client object model (sp.js) et évaluer les données côté client pour déterminer si les appels d’API doivent être effectués.
Prise en main
L’exemple Performance.Caching (exemple PnP O365) montre comment implémenter la mise en cache côté client basée sur les cookies et LocalStorage dans le modèle de module de mise en cache 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 à ces emplacements sont utilisées pour déterminer s’il est nécessaire d’effectuer des appels d’API à un SharePoint serveur.
Ce modèle stocke les données renvoyées par les appels SharePoint API 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 la 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é.
Voir la méthode CookieCheckSkip dans la classe Customizer.aspx.cs dans OD4B. Configuration.Async (exemple PnP O365) pour voir comment le code côté serveur est utilisé pour évaluer les cookies.
Mise en œuvre de votre propre couche de cache « man-in-the-middle »
Parfois, il est logique de créer votre propre couche de cache personnalisée. Par exemple, vous devez renvoyer 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 du timer à 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 SharePoint de données.
Azure dispose de nombreux mécanismes de stockage différents qui peuvent être utilisés pour stocker des informations, dont la plupart effectuent des opérations extrêmement rapides, telles que le stockage de tables 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 la 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 SharePoint Managed Code Client-side Object Model API (Microsoft.SharePoint.Client.dll) et évaluer les données côté serveur ou les cookies 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 un utilisateur.
- L’application de configurations OneDrive Entreprise personnalisées est un bon exemple de ce scénario.
Prise en main
L’exemple Performance.Caching (O365 PnP) décrit comment implémenter la mise en cache côté client basée sur les cookies et LocalStorage dans le modèle de module de mise en cache et fournit des liens vers plusieurs exemples et articles.
Liens connexes
- Articles de référence sur la page https://aka.ms/OfficeDevPnPGuidance
- Références dans MSDN sur la page https://aka.ms/OfficeDevPnPMSDN
- Vidéos sur la page https://aka.ms/OfficeDevPnPVideos
Exemples PnP
- Exemples et contenu dans Microsoft 365 et pratiques PnP (Patterns and Practices)
S’applique à
- Office 365 multi-locataire (MT).
- Office 365 dédiés (D)
- SharePoint 2013 en local