SharePoint BLOB Management – BLOB Cache

SharePoint Adventskalender – 18. Türchen

Performance Tuning – Performance Monitoring – Best-Practices für SP-SQL-Konfigurationen – BLOB Management – Backup & Recovery

————————————————————-

Heute und in den nächsten Kalendertürchen widmen wir uns dem BLOB Management für optimierte Speicherlaufwerke und der daraus resultierenden Verbesserung unserer SharePoint Performance.

Nach einer Umfrage der AIIM (Association for Information and Image Management) verzeichnen Firmen ein Datenwachstum von 50-75% pro Jahr. Durchschnittlich sind dabei von allen Daten 20% strukturiert und 80% unstrukturiert oder semi-strukturiert. Der nicht strukturierte Anteil wird in den meisten Fällen von BLOBs (Binary Large Objects) repräsentiert.

Leider ist aber die Funktionsweise eines Datenbanksystems und damit auch SQL dafür optimiert, kleine Informationspakete aus den verschiedenen Datenbanken und Tabellen zu kummulieren. Dies würd über „Queries“ realisiert und die Ergebnisse an den „Anfrager“ zurück geschickt. Die dazugehörigen Algorithmen können jedoch gar nicht gut mit großen Dateien (BLOBs) umgehen. Eine Anfrage auf eine einzige Datei mit einer Größe von 10 MB wird besipielsweise von SQL langsamer bedient, als würde ich sie direkt über das Netzwerk von einem File-Share laden. Somit ist klar, warum ein optimiertes BLOB Management große Performance-Verbesserungen für die Endnutzer bringt.

Beginnen wir mit dem vermutlich bekanntesten Ansatz, dem SharePoint BLOB Cache. Dieser speichert Dateien auf den WFEs, sodass SQL diese nicht bei einer erneuten Anfrage laden muss. Den Vorgang kann man sich vereinfacht folgendermaßen vorstellen:

 

Wie man sieht, ist auch hier der „frühe Vogel“ etwas langsamer unterwegs, weil er zunächst durch seinen Request den Cache des Servers „füttert“. Wird er bei einer Aktualisierung auf einen anderen WFE durch den Load Balancer geroutet, so muss auch da der Cache zunächst befüllt werden. Bei kleinen Bildern ist der Cache-Vorteil kaum zu spüren. Aber wenn wir von Dateien jenseits der 10 MB-Grenze reden, dann werden die Geschwindigkeitsunterschiede schnell deutlich.

Damit die jeweilige Datei zum Rendern schnell wieder gefunden werden kann, wird ein BLOB Cache Index erzeugt. Der Umfang dieses Index kann bei extrem vielen verschiedenen Dateien im Cache auch durchaus etwas größer werden. Im RAM-Speicher werden dafür etwa 800 Bytes pro Eintrag benötigt. Achten Sie daher darauf, welche Werte Sie für den BLOB Cache in der web.config-Datei der jeweiligen Web Application IIS-Webseiten konfigurieren. Sie können dabei definieren, welche Dateien ge-cached werden sollen und wie groß der Cache maximal werden darf (Angabe ist in GB! – standard sind 10 GB). Der ObjectCache definiert hingegen, wie viel vom Arbeitsspeicher für das Caching maximal verwendet werden darf (Standard = 100 MB!).

Der BLOB Cache ist jedoch nicht für alle Szenarien gut geeignet. Entscheiden Sie selbst, welche der beiden folgenden Szenarien bei Ihnen zu finden ist und werden Sie entsprechend tätig.

BLOB Caching besonders nützlich

BLOB Caching weniger nützlich

Seiten und deren Inhalte werden häufig besucht Weniger häufig genutzte Dateien
Vor allem “Rich Media”, also größere Dateien, wie Videos, sind solche Inhalte Dateien, die häufig geändert werden

Viel Spaß beim „SharePointen“!

————————————————————-

Weitere Türchen:

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.