Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03650.jsonl.gz/1693

Ihm Rahmen eines Office SharePoint Server 2007 Projektes kam die Fragen nach den Limitationen von SharePoint auf. In diesem Zusammenhang interessierte auch der Einfluss der Anzahl von Site Collections auf die Geschwindigkeit von SharePoint generell. Nun, das Web ist voll mit Angaben und Erfahrungen. Auf den TechNet Seiten von Microsoft findet man sicher die umfangreichsten technischen Sammlungen zu diesem Thema. Am konzentriertesten beschreibt die Seite „Plan for software boundaries“ die Limitationen und die Konsequenzen. Das Internet ist voll mit Erfahrungen zu einzelnen Aspekten der Skalierbarkeit und daraus resultierenden Performance Problemen.
Die ACL Limitation
Einer der Aspekte die in der SharePoint Community viel diskutiert wird ist die Limitation der ACL. Das Problem, dass in diesem Zusammenhang auftritt ist, dass der Index nicht mehr erfolgreich aktualisiert wird. Im Log File wird dann jeweils vermerkt, dass die Seite eine zu grosse Anzahl von Gruppen und Benutzern enthält. Die detaillierte Beschreibung findet man im KB 885482.
Dieses Verhalten tritt auf, weil die „Access Controll List“ (ACL) grösser als 64 Kilobyte ist. Die maximale Grösse einer ACL in Windows, inklusive der „Access Controll Entries“ (ACE) die in der ACL enthalten sind, sind einfach nur 64 Kilobyte. Gemäss dem KB 166348 gilt diese Begrenzung für alle Windows Systeme. In einer 64 KB ACL bringt man etwa 1820 ACEs unter (KB 953132). Auch die Verwendung des Kommandozeilen-Werkzeuges „icacls.exe“ ändert daran nichts.
Bedeutet das nun, dass ich maximal rund 2000 Benutzer zu einer Site Collection oder Site hinzufügen kann? Nein. Um zahlreiche Benutzer in einer Site, einer Liste oder einer Dokumentbibliothek hinzuzufügen empfiehlt es sich, eine Domänen-Gruppen (statt die Benutzer direkt), oder eine Share-Gruppe hinzufügen. Um also die Nummer von ACEs in dem SharePoint DACL Dokument für den Standort, die Liste oder die Bibliothek zu reduzieren, und gleichzeitig die Leistung zu optimieren, kann man also Domänen-Gruppen verwenden. In vielen Fällen ist das aber nicht möglich, da die logische Domänen Struktur nicht der logischen SharePoint Struktur entspricht. Nun, wenn man mit SharePoint an die Grenzen der Software-Limitationen kommt, bleibt einem nichts anderes übrig, als mit dem Active Directory Team zu sprechen, oder sich nach einer anderen Lösung umzuschauen.
Eine der Möglichkeiten wäre auf „Forms Based Authentication“ umzustellen. Mit mehr als 2000 Benutzern in einer Site,wird man diese wohl, in der Benutzerübersicht, nicht mehr darstellen können. Aber da der Index immer noch mit „Windows Authentication” und mit einem „principal“ arbeitet, wird man den ACL-Effekt nicht bemerken.
Mit all diesen Hintergrundinformationen versehen (und gemäss dem Artikel: „Plan for software boundaries“, gestaltet sich die Benutzer Ausprägung für SharePoint wie folgt:
|People Objekt||Guidelines für akzeptable Performance||Anmerkungen|
|Benutzer in Gruppen||2 Millionen pro Webseite||2 Millionen Benutzer, wenn die die ACL Grenze nicht überschritten wird.|
|Benutzer Profile||5 Millionen Pro Farm||Diese Zahl repräsentiert die Anzahl der Benutzerprofile welche erstellt werden durch entsprechende Accounts im Active Directory oder einem anderen Directory (wie etwa LDAP).|
|Security principal||Ungefähr 2’000 pro ACL (Access Control List) auf einem beliebigen Sicherheitsobjekt (scope)||Die Grösse der ACL darf 64KB nicht überschreiten.|
Tabelle 1 – Benutzer Limitationen
Architektur Grenzen
Eine weitere Frage die sich im Zusammenhang mit der SharePoint Architektur stellt war, ob man die SharePoint Seiten besser über SharedService Provider oder Web Applikationen ausbalanciert? Auch hier hilft der TechNet Artikel „ „Plan for software boundaries“ weiter. Gemäss diesen Angaben kann man die Balance in Bezug aus Performance und Limitation einfacher abschätzen:
|Logisches Architektur Objekt||Guidelines für akzeptable Performance||Anmerkungen|
|Shared Services Provider (SSP)||3 pro Farm (Maximal 20 pro Farm)|
|Zone||5 pro Farm||Die maximale Anzahl der Zonen ist beschränkt auf 5.|
|Web Applikationen||99 pro SSP||Das Limit von 99 Web Applikationen pro SSP ist inklusive der Web Applikationen einer „child farm“ die ebenfalls Ressourcen des SSP verbraucht.|
|Internet Information Services (IIS) Application Pool||8 pro Webserver||Die maximale Anzahl ist beschränkt durch die Performance des Servers.|
|Site Collection||50’000 pro Web Applikation|
|Content Database||100 pro Web Applikation|
|Site Collection||50’000 pro Datenbank|
Tabelle 2 – Architektur Grenzen
Enduser Performance
Am Ende entscheidet aber die Performance welche der Benutzer an seinem Browser erfährt, wie ausgewogen die Architektur gewählt worden ist. Trotz der enormen Anzahl von Site Collections die pro Content Datenbank möglich ist, beginnt die Performance ab 5000 Site Collections stark abzunehmen.
Abbildung 1 – Durchsatz vs. Anzahl Site Collections
|Site Object||Guidelines für akzeptable Performance||Bemerkungen||Umfang der Auswirkungen, wenn die Leistung abnimmt|
|Site collection||50’000 pro Content Datenbank||Der totale Durchsatz der Farm beginnt mit der Anzahl der Site Collections zu sinken. Siehe dazu Grafik 1||Farm|
|Site collection||150’000 pro Web Applikation||Diese Limitation ist lediglich theorethischer Natur. Sie ist abhängig von:

– Performance der Datenbank Server
– Performance der Web Server der Farm
– Netzwerk-Bandbreite zwischen Webserver und Datenbank Server
|Farm|
|Web site||250’000 pro Site Collection||Diese hohe Zahl kommt zustande, weil man in SharePoint subsites in eine Site einbetten kann. Zum Beispiel: 100 Sites, jede mit 1000 Subsites, sind 100’000 Websites.

Die maximale Anzahl die von Microsoft empfohlen wird ist: 125 Sites, mit jeweils 2000 Subseiten für jede. Was auf das empfohlene 250’000 Seiten hinausläuft.
|Site Collection|
|Subsite||2’000 pro Website||Die grafische Darstellen, wenn man sich die Seitenübersicht anzeigen lässt, verlangsamt sich ab 2000 Seiten.||Seitenansicht|
|Dokumente||5 Millionen pro Bibliothek||Auch diese grosse Zahl kann nur zustande kommen wenn die Dokumente in Unterordner eingebetet warden. Ansonsten sind 2000 Dokumente zu empfehlen.||Library|
|Item||2’000 pro Ansicht||Listen Ansicht|
|Dokument Grösse||50MB (2GB Maximal)||Bibliothek, Performance beim speichern|
|Liste||2’000 pro Website||Mehr Informationen unter: White paper: Working with large lists in Office SharePoint Server 2007.||Listen Ansicht|
|Field type||256 pro Liste||Das ist kein „hard limit“ jedoch ist eine Performance Einbusse über dieser Grenze zu bemerken||Listen Ansicht|
|Spalten||2’000 pro Dokumenten Bibliothek

4,096 pro Liste
|Das ist kein „hard limit“ jedoch ist eine Performance Einbusse über dieser Grenze zu bemerken||Bibliotheken und „list view“|
|Web Part||50 pro Seite||Das ist kein „hard limit“ jedoch ist eine Performance Einbusse über dieser Grenze zu bemerken. Basierend auf der Komplexität des Codes können aber Performanceeinbussen deutlich früher eintreten||Seite|
|Managed path||20 pro Web Application||Das ist kein „hard limit“ jedoch können sich Performance Einbusse über dieser Grenze zu bemerkbar machen.

Managed paths werden auf dem Webserver gecached. Somit sind dessen Performance (CPU, RAM, Disk I/O) entscheidend für den Durchsatz. Es empfiehlt sich die Performance zu testen , wenn sich der Grenze von 20 Managed path nähert.
|Web Applikation|