Le tableau suivant répertorie les recommandations pour les applications web.
Application web
20 par batterie de serveurs
Pris en charge
Nous vous recommandons de limiter autant que possible le nombre d’applications web. Dans la mesure du possible, créez des collections de sites nommées par l’hôte supplémentaires au lieu d’ajouter des applications web.
Zone
5 par application web
Frontière
Le nombre de zones définies pour une batterie de serveurs est codé en dur sur 5. Les zones sont Par défaut, Intranet, Extranet, Internet et Personnalisée.
Chemin d’accès géré pour les collections de sites nommées par l’hôte
20 par batterie de serveurs
Pris en charge
Les chemins d’accès gérés pour les collections de sites nommées par l’hôte s’appliquent au niveau de la batterie de serveurs. Chaque chemin d’accès géré créé peut être appliqué dans n’importe quelle application web.
Chemin d’accès géré pour les collections de sites basées sur le chemin d’accès
20 par application web
Pris en charge
Les chemins d’accès gérés sont mis en cache sur le serveur web, et les ressources processeur sont utilisées pour le traitement des demandes entrantes par rapport à la liste des chemins d’accès gérés.
Les chemins d’accès gérés pour les collections de sites basées sur le chemin d’accès s’appliquent au niveau de l’application web. Vous pouvez créer un ensemble différent de chemins d’accès gérés par application web. Si le nombre de chemins d’accès gérés par application web est supérieur à 20, la charge sur le serveur web est accrue pour chaque demande.
Si vous envisagez de dépasser vingt chemins d’accès gérés dans une application web donnée, nous vous recommandons de procéder à des tests afin de déterminer si le système peut atteindre des performances acceptables.
Taille du cache des solutions
300 Mo par application web
Seuil
Le service InfoPath Forms peut conserver les solutions dans le cache des solutions afin d’accélérer leur récupération. Si la taille du cache est dépassée, les solutions sont récupérées à partir du disque, ce qui peut ralentir les temps de réponse. Vous pouvez configurer la taille du cache des solutions à l’aide de l’applet de commande Windows PowerShell Set-SPInfoPathFormsService. Pour plus d’informations, voir Set-SPInfoPathFormsService.
Le tableau suivant répertorie les recommandations pour les serveurs web de la batterie de serveurs.
Pools d’applications
10 par serveur web
Seuil
Le nombre maximal est déterminé par les capacités matérielles.
Cette limite dépend en grande partie :
de la quantité de mémoire allouée aux serveurs web ;
de la charge de travail assurée par la batterie de serveurs, c’est-à-dire des caractéristiques de la base des utilisateurs et de l’utilisation (un seul pool d’applications très actif peut utiliser 10 Go ou plus).
Le tableau suivant répertorie les recommandations pour les bases de données de contenu.
Nombre de bases de données de contenu
500 par batterie de serveurs
Pris en charge
Le nombre maximal de bases de données de contenu par batterie de serveurs est de 500. Avec 500 bases de données de contenu par application web, les opérations des utilisateurs finals, telles que l’ouverture du site ou des collections de sites, ne sont pas affectées. Par contre, les opérations d’administration, telles que la création d’une collection de sites, subissent une diminution des performances. Nous vous recommandons d’utiliser Windows PowerShell pour gérer l’application web en présence de nombreuses bases de données de contenu, car l’interface de gestion peut devenir lente et difficile à parcourir.
Avec 200 Go par base de données de contenu et 500 bases de données de contenu par batterie de serveurs, SharePoint Server 2013 prend en charge 100 To de données par batterie de serveurs.
Taille de la base de données de contenu (scénarios d’utilisation générale)
200 Go par base de données de contenu
Pris en charge
La taille par défaut est de 50 Mo, elle peut être augmentée jusqu’à 2 Go au maximum. Vous pouvez faire rentrer 100 fichiers dans chaque base de données de contenu. Plusieurs collections de sites peuvent partager une seule base de données de contenu. Chaque collection de sites doit être entièrement stockée dans une base de données de contenu unique.
Nous recommandons fortement de limiter la taille des bases de données de contenu à 200 Go, sauf lorsque les circonstances indiquées dans les lignes suivantes de ce tableau s’appliquent.
Si vous utilisez le stockage étendu des objets BLOB, le volume total du stockage étendu des objets BLOB et des métadonnées dans la base de données de contenu ne doit pas dépasser la limite de 200 Go.
Taille de la base de données de contenu (tous les scénarios d’utilisation)
4 To par base de données de contenu
Pris en charge
Les bases de données de contenu allant jusqu’à 4 To sont prises en charge lorsque la configuration requise suivante est satisfaite :
Performances du sous-système de disques de 0,25 opération d’entrée/sortie par seconde par Go. 2 opérations d’entrée/sortie par seconde par Go sont recommandées pour des performances optimales.
Vous devez avoir développé des plans de haute disponibilité, de récupération d’urgence, de capacité future et de test des performances.
Vous devez également considérer soigneusement les facteurs suivants :
La configuration requise pour la sauvegarde et la restauration risque de ne pas être satisfaite par la sauvegarde SharePoint Server 2013 native des bases de données de contenu supérieures à 200 Go. Il est recommandé d’évaluer et de tester la sauvegarde SharePoint Server 2013 et des solutions de sauvegarde alternatives pour déterminer la solution la mieux adaptée à votre environnement spécifique.
Il est vivement recommandé de mettre en place une gestion proactive par un administrateur compétent des installations SharePoint Server 2013 et SQL Server.
Exemples
La refactorisation de collections de sites permet de monter en charge une implémentation SharePoint Server 2013 sur plusieurs bases de données de contenu. Cela permet aux implémentations SharePoint Server 2013 de s’étendre indéfiniment. Cette refactorisation est plus facile et plus rapide lorsque les bases de données de contenu sont inférieures à 200 Go.
Il est suggéré, pour faciliter la sauvegarde et la restauration, de limiter les collections de sites individuelles au sein d’une base de données de contenu à 100 Go. Pour plus d’informations, voirLimites des collections de sites.
Taille de la base de données de contenu (scénario d’archivage de documents)
Aucune limite explicite sur la base de données de contenu
Pris en charge
Les bases de données de contenu sans limite de taille explicite utilisées dans des scénarios d’archivage de documents sont prises en charge lorsque la configuration requise suivante est satisfaite :
Vous devez satisfaire toutes les exigences liées à la limite « Taille de la base de données de contenu (tous les scénarios d’utilisation) » précédemment indiquée dans ce tableau et vous devez veiller à avoir attentivement examiné tous les facteurs décrits dans le champ Commentaires de cette limite.
Les sites SharePoint Server 2013 doivent s’appuyer sur les modèles de sites Centre de documentsou Centre des enregistrements.
En moyenne, chaque mois, les utilisateurs accèdent à moins de 5 % du contenu de la base de données de contenu, et modifient ou écrivent moins de 1 % du contenu.
- Remarque : Il est possible de configurer les bases de données de contenu d’archivage de documents afin d’accepter les documents provenant de flux de travail de routage de contenu.
N’utilisez pas d’alertes, de flux de travail, de réparations des liens ni de sécurité au niveau de l’élément sur tous les objets SharePoint Server 2013 compris dans la base de données de contenu.
Pour plus d’informations sur les référentiels de documents à grande échelle, voir Estimation des conditions requises en matière de performance et de capacité pour les référentiels de documents à grande échelle dans SharePoint Server 2010, ainsi que la section Scénarios classiques de gestion de contenu à grande échelle de l’article Planification du stockage de contenu d’entreprise (SharePoint Server 2010).
Éléments de base de données de contenu
60 millions d’éléments, documents et éléments de liste compris
Pris en charge
Le plus grand nombre d’éléments par base de données de contenu qui a été testé sur SharePoint Server 2013 s’élève à 60 millions, documents et éléments de liste compris. Si vous envisagez de stocker plus de 60 millions d’éléments dans SharePoint Server 2013, vous devez déployer plusieurs bases de données de contenu.
Collections de sites par base de données de contenu
10 000 maximum (soit 2 500 collections de sites non personnelles et 7 500 sites personnels, soit 10 000 sites personnels)
Pris en charge
Nous avons vivement recommandé de limiter à 5 000 le nombre de collections de sites dans une base de données de contenu. Toutefois, le nombre maximal de collections de sites pouvant être prises en charge dans une base de données s’élève à 10 000. Notez que dans une base de données de contenu comportant jusqu’à 10 000 collections de sites, 2 500 d’entre elles au maximum peuvent être des collections de sites non personnelles. Il est possible de prendre en charge 10 000 collections de sites personnelles si ce sont les seules collections de sites dans la base de données de contenu.
Ces limites concernent la vitesse de la mise à niveau. Plus le nombre de collections de sites est élevé dans une base de données, plus la mise à niveau est lente par rapport à la mise à niveau de la base de données et aux mises à niveau des collections de sites.
La limite du nombre de collections de sites dans une base de données est tributaire de la taille limite d’une base de données de contenu qui comporte plusieurs collections de sites. Par conséquent, à mesure qu’augmente le nombre de collections de sites dans une base de données, la taille moyenne des collections de sites qu’elle contient doit diminuer.
Le dépassement de la limite de 5 000 collections de sites risque d’entraîner des temps morts plus longs pendant les mises à niveau. Si vous envisagez de dépasser 5 000 collections de sites, nous vous recommandons de mettre en œuvre une stratégie de mise à niveau précise pour faire face à la longueur des temps d’arrêt et à l’impact sur les opérations et de renforcer la configuration matérielle pour accélérer les mises à niveau et les mises à jour logicielles qui ont un impact sur les bases de données.
Pour définir le niveau d’avertissement et le niveau maximal du nombre de sites dans une base de données de contenu, utilisez l’applet de commande Windows PowerShell Set-SPContentDatabase avec le paramètre -WarningSiteCount. Pour plus d’informations, voir Set-SPContentDatabase.
Sous-système de stockage étendu des objets blob (RBS) sur le serveur NAS (Network Attached Storage)
Le temps d’attente du premier octet d’une réponse en provenance du serveur NAS ne doit pas dépasser 40 millisecondes 95 % du temps.
Frontière
Lorsque SharePoint Server 2013 est configuré pour utiliser RBS et que des objets BLOB résident sur le support de stockage NAS, envisagez la limite prise en charge suivante.
Entre le moment où SharePoint Server 2013 demande un objet BLOB et le moment où il reçoit le premier octet de la part du serveur NAS, 95 % du temps, pas plus de 40 millisecondes ne peuvent s’écouler.
Le tableau suivant répertorie les recommandations pour les collections de sites.
Collections de sites par batterie de serveurs
750 000 (500 000 sites personnels et 250 000 autres sites par batterie de serveurs)
Pris en charge
Le nombre recommandé maximal de collections de sites par batterie de serveurs est 500 000 sites personnels plus 250 000 pour tous les autres modèles de sites. Les sites peuvent tous résider sur une seule application web ou peuvent être répartis dans plusieurs applications web.
Notez que cette limite est affectée par d’autres facteurs susceptibles de réduire le nombre effectif de collections de sites qu’une base de données de contenu donnée peut prendre en charge. Il est nécessaire d’être prudent afin d’éviter de dépasser les limites prises en charge quand un objet conteneur, tel qu’une base de données de contenu, contient un grand nombre d’autres objets. Par exemple, si une batterie de serveurs contient un nombre total réduit de bases de données de contenu comportant chacune un nombre élevé de collections de sites, les performances de la batterie de serveurs risquent d’être affectées longtemps avant que ne soit atteint le nombre maximal de collections de sites pris en charge.
Par exemple, la batterie A contient une application web qui comporte 200 bases de données de contenu, une configuration prise en charge. Si chacune de ces bases de données de contenu contient 1 000 collections de sites, le nombre total de collections de sites dans l’application web atteint 200 000, ce qui se situe dans les limites prises en charge. En revanche, si chaque base de données de contenu contient 10 000 collections de sites, même si ce nombre est pris en charge pour une base de données de contenu, le nombre total de collections de sites dans la batterie de serveurs s’élève à 2 000 000, ce qui dépasse la limite du nombre de collections de sites par application web.
L’utilisation de la mémoire sur les serveurs web doit être surveillée, car elle est tributaire de modèles d’utilisation et des modalités d’accès à un nombre élevé de sites dans une période donnée. De même, les cibles d’analyse risquent de faire également état d’une pression de mémoire, situation dans laquelle le pool d’applications doit être configuré de manière à ce qu’il soit recyclé avant que la mémoire disponible sur chaque serveur web ne soit inférieure à 2 Go.
Site web
250 000 par collection de sites
Pris en charge
Le nombre recommandé maximal de sites et de sous-sites est de 250 000.
Vous pouvez créer un nombre total de sites web très élevé en imbriquant des sous-sites. Par exemple, dans une hiérarchie peu profonde de 100 sites, comportant chacun 1 000 sous-sites, vous disposez d’un total de 100 000 sites web. De même, dans une hiérarchie profonde de 100 sites, comportant chacun 10 niveaux de sous-site, vous disposez également d’un total de 100 000 sites web.
Remarque : la suppression ou la création d’un site ou d’un sous-site peut avoir un impact significatif sur la disponibilité d’un site. L’accès au site et aux sous-sites est limité pendant la suppression du site. En outre, une tentative de créer de nombreux sous-sites en même temps peut échouer.
Taille des collections de sites
Taille maximale de la base de données de contenu
Pris en charge
Une collection de sites peut atteindre le volume limite de la taille de base de données de contenu du scénario d’utilisation applicable. Pour plus d’informations sur les différentes limites de la taille de base de données de contenu pour des scénarios d’utilisation spécifiques, voir le tableau Limites des bases de données de contenu dans cet article.
En général, nous recommandons vivement de limiter la taille des collections de sites à 100 Go pour les raisons suivantes :
Certaines actions sur les collections de sites, telles que la sauvegarde/restauration d’une collection de sites ou l’applet de commande Windows PowerShell Move-SPSite, entraînent des opérations SQL Server d’envergure qui peuvent avoir une influence sur les performances ou échouer si d’autres collections de sites sont actives dans la même base de données. Pour plus d’informations, voir Move-SPSite.
La sauvegarde et la restauration des sites SharePoint est uniquement prise en charge pour une taille de collection de sites maximale s’élevant à 100 Go. Pour les collections de sites plus volumineuses, il est nécessaire de sauvegarder la totalité de la base de données de contenu. Si plusieurs collections de sites supérieures à 100 Go sont comprises dans une base de données de contenu unique, les opérations de sauvegarde et de restauration peuvent prendre longtemps et risquent d’échouer.
Nombre de canaux d’appareil par collection de sites de publication
10
Frontière
Le nombre maximal de canaux d’appareil autorisé par collection de sites de publication s’élève à 10.
Le tableau suivant répertorie les recommandations pour les listes et les bibliothèques. Pour plus d’informations, voir Conception de grandes listes et optimisation des performances des listes (SharePoint Server 2010).
Taille des lignes des listes
8 000 octets par ligne
Frontière
Chaque élément de liste ou de bibliothèque ne peut occuper que 8 000 octets au total dans la base de données. 300 octets sont réservés, ce qui laisse 7 700 octets pour les colonnes des utilisateurs finals. Pour plus d’informations sur la quantité d’espace consommée par chaque type de champ, voir Limites des colonnes.
Taille des fichiers
2 Go
Frontière
La taille de fichier maximale par défaut est de 250 Mo. Cette limite est configurable et peut être augmentée jusqu’à 2 Go (2 047 Mo). Toutefois, une quantité élevée de fichiers très volumineux peut avoir une incidence sur les performances de la batterie de serveurs.
Documents
30 000 000 par bibliothèque
Pris en charge
Vous pouvez créer des bibliothèques de documents très volumineuses en imbriquant des dossiers ou en utilisant une hiérarchie de site et des affichages standard. Cette valeur peut varier suivant la façon dont les documents et les dossiers sont organisés et en fonction du type et de la taille des documents stockés.
Versions principales
400 000
Pris en charge
Si vous dépassez cette limite, les opérations de base sur les fichiers, telles que l’ouverture, l’enregistrement, la suppression d’un fichier et l’affichage de l’historique des versions, risquent d’échouer.
Version mineure
511
Frontière
Le nombre maximal de versions de fichier mineures s’élève à 511. Cette limite ne peut pas être dépassée.
Éléments
30 000 000 par liste
Pris en charge
Vous pouvez créer des listes très volumineuses en utilisant la navigation par métadonnées, des hiérarchies de site et des affichages standard. Cette valeur peut varier suivant le nombre de colonnes dans la liste et l’utilisation de celle-ci.
Opérations en bloc
100 éléments par opération en bloc
Frontière
L’interface utilisateur permet de sélectionner au maximum 100 éléments pour les opérations en bloc.
Seuil de recherche d’affichage de liste
12 opérations de jointure par requête
Seuil
Spécifie le nombre maximal de jointures autorisées par requête, telles que celles basées sur des colonnes de recherche, personne/groupe ou d’état de flux de travail. Si la requête utilise plus de huit jointures, l’opération est bloquée. Ceci ne s’applique pas à des opérations sur un seul élément. Lors de l’utilisation de l’affichage maximal via le modèle objet (en ne spécifiant aucun champ d’affichage), SharePoint retourne jusqu’aux 12 premières recherches.
Remarque : Après avoir appliqué le package de mise à jour cumulative de SharePoint Server 2013 publié le 13 août 2013 (https://support.microsoft.com/fr-fr/kb/2817616), la valeur par défaut est augmentée de 8 à 12.
Seuil d’affichage de liste
5,000
Seuil
Spécifie le nombre maximal d’éléments de liste ou de bibliothèque qu’une opération de base de données telle qu’une requête peut traiter en même temps en dehors de la fenêtre de temps quotidienne définie par l’administrateur, au cours de laquelle les requêtes ne sont pas limitées.
Seuil d’affichage de liste pour les auditeurs et les administrateurs
20,000
Seuil
Spécifie le nombre maximal d’éléments de liste ou de bibliothèque qu’une opération de base de données telle qu’une requête peut traiter en même temps lorsqu’elle est effectuée par un auditeur ou un administrateur ayant les autorisations appropriées. Ce paramètre fonctionne avec Autoriser le remplacement du modèle objet.
Sous-site
2 000 par affichage de site
Seuil
L’interface permettant d’énumérer les sous-sites d’un site web donné est moins performante dès que le nombre de sous-sites est supérieur à 2 000. De même, les performances de la page Tout le contenu du site et du contrôle arborescence diminuent sensiblement à mesure que le nombre de sous-sites croît.
Co-création dans Word et PowerPoint pour des fichiers .docx, .pptx et .ppsx
10 éditeurs simultanés par document
Seuil
Le nombre maximal recommandé d’éditeurs simultanés est de 10. La frontière est 99.
Si 99 co-auteurs travaillent simultanément sur un même document ouvert, chaque utilisateur suivant obtient l’erreur « Fichier en cours d’utilisation » et peut uniquement ouvrir une copie en lecture seule.
Dès que le nombre de co-éditeurs est supérieur à 10, l’expérience utilisateur se dégrade progressivement en raison du nombre croissant de conflits et les utilisateurs risquent de s’y prendre à plusieurs reprises pour télécharger correctement leurs modifications vers le serveur.
Étendue de sécurité
50 000 par liste
Seuil
Le nombre maximal d’étendues de sécurité uniques défini pour une liste ne peut être supérieur à 50 000.
Pour la plupart des batteries de serveurs, nous vous recommandons de diminuer cette limite à 5 000 étendues uniques. Pour les grandes listes, privilégiez une conception qui utilise le moins d’autorisations uniques possible.
Quand le nombre d’étendues de sécurité uniques pour une liste dépasse la valeur du seuil d’affichage de liste (défini par défaut sur 5 000 éléments de liste), l’affichage de la liste donne lieu à des allers-retours SQL Server supplémentaires, ce qui peut affecter les performances de l’affichage des listes.
Une étendue constitue la frontière de sécurité pour un objet sécurisable et tous ses enfants pour lesquels aucune frontière de sécurité distincte n’est définie. Une étendue contient une liste de contrôle d’accès, mais à la différence des listes de contrôle d’accès NTFS, une étendue peut inclure des principaux de sécurité propres à SharePoint Server 2013. Les membres d’une liste de contrôle d’accès pour une étendue peuvent comprendre des utilisateurs Windows, des comptes d’utilisateur autres que des utilisateurs Windows (tels que des comptes basés sur des formulaires), des groupes Active Directory ou des groupes SharePoint.
Les données SharePoint Server 2013 sont stockées dans des tables SQL Server. Pour autoriser le nombre maximal de colonnes possible dans une liste SharePoint, SharePoint Server 2013 crée plusieurs lignes dans la base de données lorsque les données ne contiennent pas dans une seule ligne. Cette opération s’appelle « retour automatique à la ligne ».
À chaque retour à la ligne dans SQL Server, une charge de requête supplémentaire est soumise au serveur lorsque cet élément est interrogé, car une jointure SQL doit être incluse dans la requête. Pour que les charges ne soient pas excessives, par défaut, au maximum six lignes SQL Server sont autorisées pour un élément SharePoint. Cette limite se traduit par une limitation spécifique du nombre de colonnes de chaque type pouvant être incluses dans une liste SharePoint. Le tableau suivant décrit les limites pour chaque type de colonne.
Le paramètre de retour automatique à la ligne peut être augmenté au-delà de six, mais cela risque de se traduire par des charges excessives sur le serveur. Nous vous recommandons de tester les performances avant de dépasser cette limite.
La valeur de la taille de chaque type de colonne est indiquée en octets. La somme de toutes les colonnes dans une liste SharePoint ne peut pas dépasser 8 000 octets. Suivant l’utilisation de la colonne, les utilisateurs peuvent atteindre la limite de 8 000 octets avant d’atteindre la limite de six lignes spécifique au retour automatique à la ligne.
Une seule ligne de texte
255
Seuil
30 octets
Plusieurs lignes de texte
350
Seuil
22 octets
Choix
255
Seuil
30 octets
Choix (plusieurs sélections)
350
Seuil
22 octets
Nombre
550
Seuil
14 octets
Monétaire
550
Seuil
14 octets
Date et heure
550
Seuil
14 octets
Recherche
750
Seuil
10 octets
Oui/Non
1000
Seuil
7 octets
Personne ou groupe
750
Seuil
10 octets
Lien hypertexte ou image
127
Seuil
60 octets
Le retour automatique à la ligne SQL Server se produit après chaque groupe de 32 colonnes dans une liste SharePoint. La valeur par défaut du retour automatique à la ligne (6) autorise un maximum de 192 colonnes de type Lien hypertexte ou image par liste SharePoint (6 * 32 = 192). Toutefois, la limite par élément de liste SharePoint étant de 8 000 octets, dont 256 réservés pour les colonnes SharePoint prédéfinies, la limite réelle doit être de 138 colonnes de type Lien hypertexte ou image.
Calculé
255
Seuil
30 octets
Le retour automatique à la ligne SQL Server se produit après chaque groupe de 8 colonnes dans une liste SharePoint. La valeur par défaut du retour automatique à la ligne (6) autorise un maximum de 48 colonnes de type Calculé par liste SharePoint (6 * 8 = 48).
GUID
350
Seuil
22 octets
Le retour automatique à la ligne SQL Server se produit après chaque colonne dans une liste SharePoint. La valeur par défaut du retour automatique à la ligne (6) autorise un maximum de 6 colonnes de type GUID par liste SharePoint (6 * 1 = 6).
Int
750
Seuil
10 octets
Le retour automatique à la ligne SQL Server se produit après chaque groupe de 16 colonnes dans une liste SharePoint. La valeur par défaut du retour automatique à la ligne (6) autorise un maximum de 96 colonnes de type Ent par liste SharePoint (6 * 16 = 96).
Métadonnées gérées
190
Seuil
60 octets pour la première, 40 octets pour chacune des suivantes
Quatre colonnes sont allouées au premier champ Métadonnées gérées ajouté à une liste :
Un champ Liste de choix pour la balise réelle
Un champ de texte masqué pour la valeur de chaîne
Un champ Liste de choix pour le fourre-tout
Un champ Liste de choix pour les éléments n’appartenant pas au fourre-tout
Chaque ajout de champ Métadonnées gérées à une liste se traduit par l’ajout de deux colonnes :
Le nombre maximal de colonnes de métadonnées gérées est égal à (14 + (16 * (n-1))) où n représente la valeur du mappage de lignes (6 par défaut).
Géolocalisation
2
Seuil
30 octets
Les colonnes de type Données externes présentent le concept de colonne principale et de colonnes secondaires. Lorsque vous ajoutez une colonne de données externes, vous pouvez sélectionner certains champs secondaires de type contenu externe en vue de les ajouter à la liste. Par exemple, dans le cas d’un type de contenu externe « Client » qui possède des champs tels que les champs « ID », « Nom », « Pays » et « Description », lorsque vous ajoutez une colonne de données externes de type « Client » à une liste, vous pouvez ajouter des champs secondaires pour afficher les « ID », « Nom », « Pays » et « Description » du client. Dans l’ensemble, les colonnes ajoutées sont les suivantes :
Colonne principale : un champ texte.
Colonne ID masqué : un champ texte multiligne.
Colonnes secondaires : chaque colonne secondaire est un champ texte/nombre/booléen/texte multiligne basé sur le type de données de la colonne secondaire définie dans le modèle du catalogue de données métiers. Par exemple, ID peut être mappé sur une colonne Nombre, Nom sur une colonne Une seule ligne de texteet Description sur une colonne Plusieurs lignes de texte.
Le tableau suivant répertorie les recommandations pour les pages.
Composants WebPart
25 par page Wiki ou page de composants WebPart
Seuil
Ce chiffre est une estimation basée sur des composants WebPart simples. La complexité des composants WebPart détermine le nombre de composants WebPart pouvant être utilisés sans que les performances soient affectées.
Nombre de groupes SharePoint auxquels un utilisateur peut appartenir
5,000
Pris en charge
Cette limite n’est pas codée en dur, mais elle est cohérente avec les recommandations Active Directory. Plusieurs éléments ont une incidence sur ce nombre :
La taille du jeton d’utilisateur.
Le cache des groupes : SharePoint Server 2013 possède une table qui met en cache le nombre de groupes auxquels un utilisateur appartient dès que ces groupes sont utilisés dans des listes de contrôle d’accès.
La durée de la vérification de sécurité : lorsque le nombre de groupes dont un utilisateur est membre augmente, la durée nécessaire pour la vérification de l’accès augmente également.
Utilisateurs dans une collection de sites
2 millions par collection de sites
Pris en charge
Vous pouvez ajouter des millions de personnes à votre site web à l’aide de groupes de sécurité Microsoft Windows pour gérer la sécurité, au lieu d’utiliser des utilisateurs individuels.
Cette limite repose sur la facilité de gestion et de navigation dans l’interface utilisateur.
Lorsque la collection de sites comprend plus d’un millier d’entrées (groupes de sécurité d’utilisateurs), vous devez employer Windows PowerShell pour gérer les utilisateurs, au lieu de l’interface utilisateur. Cela procure une meilleure expérience en matière de gestion.
Utilisateurs/principaux Active Directory dans un groupe SharePoint
5 000 par groupe SharePoint
Pris en charge
SharePoint Server 2013 vous permet d’ajouter des utilisateurs ou des groupes Active Directory à un groupe SharePoint.
Vous pouvez obtenir des performances acceptables dans la limite de 5 000 utilisateurs (ou utilisateurs ou groupes Active Directory) dans un groupe SharePoint.
Les activités les plus concernées par cette limite sont les suivantes :
Extraction d’utilisateurs pour valider les autorisations. Cette opération prend d’autant plus de temps que le nombre d’utilisateurs dans un groupe est élevé.
Rendu de l’appartenance de l’affichage. Cette opération prend toujours du temps.
Groupes SharePoint
10 000 par collection de sites
Pris en charge
Au-delà de 10 000 groupes, la durée d’exécution des opérations augmente de manière significative. Cela est particulièrement vrai pour l’ajout d’un utilisateur à un groupe existant, la création d’un groupe et le rendu des affichages de groupes.
Principal de sécurité : taille de l’étendue de sécurité
5 000 par liste de contrôle d’accès
Pris en charge
La taille de l’étendue a une incidence sur les données utilisées pour le calcul d’une vérification de sécurité. Ce calcul est effectué chaque fois que l’étendue change. Il n’existe pas de limite codée en dur, mais plus l’étendue est grande, plus la durée du calcul est longue.
Cette section répertorie les limites par fonctionnalité.
Les instructions recommandées pour la recherche sont organisées selon les aspects de la recherche sur lesquels elles ont un impact : la topologie, la taille des éléments, les dictionnaires, les analyses, les schémas, les requêtes et résultats, le classement et l’index.
Les limites de topologie permettent de garantir une communication efficace entre les composants de recherche. Le dépassement de ces limites ralentit la communication entre les composants de recherche, ce qui peut entraîner des latences de requête plus élevées et, en fin de compte, un temps d’arrêt de la recherche.
Composants de traitement de l’analyse
6 par application de service de recherche ; 1 par serveur
Pris en charge
Bases de données de création de rapports d’analyse
4 par application de service de recherche
Seuil
Vous pouvez dépasser cette limite afin de tenir compte d’exigences spécifiques. Lors de la mise à l’échelle, ajoutez une base de données de création de rapports d’analyse si l’une des bases de données d’analyse déployées atteint une taille totale de 250 Go ou un nombre total de lignes de 20 millions. Le repartitionnement est ainsi aussi équilibré que possible.
Bases de données de liens
4 par application de service de recherche
Pris en charge
Le plus grand nombre d’éléments testés qu’une base de données de liens peut contenir est de 100 millions.
Composants d’analyse
16 par application de service de recherche ; 1 par serveur
Pris en charge
Composants d’index
60 par application de service de recherche ; 4 par serveur
Pris en charge
Pour calculer le nombre de composants d’index dont vous disposez, multipliez le nombre de partitions d’index par le nombre de réplicas d’index.
Pour SharePoint Foundation 2013, cette limite est fixée à un composant d’index par application de service de recherche et ne peut pas être dépassée.
Partitions d’index
25 par application de service de recherche
Pris en charge
Une partition d’index contient un sous-ensemble de l’index de l’application de service de recherche. Si vous augmentez le nombre de partitions d’index, chaque partition contient un sous-ensemble plus petit de l’index, ce qui réduit la mémoire RAM et l’espace disque nécessaires sur les serveurs qui hébergent les d’index.
Pour SharePoint Foundation 2013, le nombre maximal de composants d’index par application de service de recherche est 1, qui est aussi la limite du nombre maximal de partitions d’index par application de service de recherche.
Copies d’index
3 par partition d’index
Pris en charge
Chaque partition d’index peut posséder un ensemble de copies. Si vous augmentez le nombre de copies d’index, cela se traduit par une amélioration des performances des requêtes et par une meilleure tolérance de panne. Toutefois, si vous ajoutez trop de copies à votre partition d’index, cela peut avoir une incidence négative sur l’indexation.
Dans des scénarios de type sites Internet, qui présentent généralement un taux de requête élevé mais un volume de contenu faible (moins de 4 millions d’éléments par partition), la limite prise en charge est de 6 copies d’index par partition.
Pour SharePoint Foundation 2013, le nombre maximal de composants d’index par application de service de recherche est 1, qui est aussi la limite du nombre maximal de réplicas d’index par application de service de recherche.
Composants de traitement de contenu
1 par serveur
Pris en charge
La topologie de recherche prend en charge la mise à l’échelle du nombre de composants de traitement de contenu. Bien qu’un hôte physique ou un ordinateur virtuel spécifique prenne en charge plusieurs composants de traitement de contenu, vous optimisez la capacité de l’UC en utilisant un seul composant de traitement de contenu. En effet, un mécanisme intégré ajuste le nombre de sessions de chargement en fonction des cœurs d’UC disponibles. Plusieurs sessions de chargement permettent au composant de traitement de contenu de traiter les documents entrants en parallèle. Ce mécanisme suppose la présence d’un seul composant de traitement de contenu par hôte.
Si le nombre de cœurs physiques sur l’hôte est égal à N, le composant de traitement de contenu détient N*K sessions de chargement, K étant un coefficient constant dont la valeur initiale est 3. Un serveur équipé de 4 cœurs détient 12 sessions de chargement, ce qui signifie que le composant de traitement de contenu peut traiter 12 documents en parallèle. Vous pouvez modifier la valeur de K en définissant la propriété NumberOfCssFeedersPerCPUForRegularCrawl de l’application de service de recherche. SharePoint 2013 limite la valeur de N à 12, même si un serveur possède plus de 12 cœurs physiques. Par conséquent, un serveur équipé de 16 cœurs détient 36 (N * K = 12 * 3) sessions de chargement.
En cas de temps d’inactivité au niveau de l’UC, pensez à augmenter le coefficient K au lieu d’ajouter un composant de traitement de contenu. Si vous augmentez le coefficient K, vous devez vérifier que l’hôte dispose de suffisamment de mémoire.
Composants de traitement des requêtes
1 par serveur
Pris en charge
SharePoint 2013 prend uniquement en charge un composant de traitement des requêtes par ordinateur physique ou virtuel.
Composants de recherche
64 par application de service de recherche
Pris en charge
Cette limite n’inclut pas les composants d’analyse. La somme des autres composants de recherche ne doit pas dépasser cette limite.
Applications de service de recherche
20 par batterie de serveurs
Pris en charge
Plusieurs applications de service de recherche peuvent être déployées sur une même batterie de serveurs, car vous pouvez affecter des bases de données et des composants de recherche à différents serveurs. Cette limite est inférieure au nombre total maximal d’applications de service autorisé dans une batterie de serveurs.
Sources de contenu
500 par application de service de recherche
Frontière
Il existe une surcharge associée à chaque source de contenu. Par conséquent, nous vous recommandons de créer le plus petit nombre de sources de contenu répondant à vos autres exigences opérationnelles, par exemple des différences de priorité et de planification d’analyse.
/image%2F1495421%2F20230129%2Fob_af1f8c_2023-01-29-0oc-kleki-1.png)
/image%2F1495421%2F20230129%2Fob_e9f4fb_2023-01-29-0mm-kleki.png)
/image%2F1495421%2F20230129%2Fob_447382_2023-01-29-0lq-kleki.png)
/image%2F1495421%2F20230129%2Fob_b890a1_2023-01-29-0m9-kleki.png)
/image%2F1495421%2F20230129%2Fob_266624_2023-01-29-0lp-kleki.png)
/image%2F1495421%2F20230129%2Fob_d159cb_2023-01-29-0ms-kleki.png)
/image%2F1495421%2F20230129%2Fob_5ebbd6_2023-01-29-0n9-kleki.png)
/image%2F1495421%2F20230129%2Fob_5800e1_2023-01-29-0nf-kleki.png)
/image%2F1495421%2F20230129%2Fob_7c9112_2023-01-29-0ni-kleki.png)
/image%2F1495421%2F20230129%2Fob_6ce6c0_2023-01-29-0nn-kleki.png)
/image%2F1495421%2F20230129%2Fob_99c17c_2023-01-29-0o8-kleki.png)
/image%2F1495421%2F20201102%2Fob_8c1df7_project-for-the-web.png)
/image%2F1495421%2F20201102%2Fob_99c666_ppm-2021.png)
/image%2F1495421%2F20201102%2Fob_4f1c21_roadmap-ppm.png)
/image%2F1495421%2F20201102%2Fob_becbfd_bi-powerbi-ppm-dashboard.png)
/image%2F1495421%2F20201102%2Fob_bacfd9_project-online-variants-e.png)
