Was beeinflusst die SharePoint Performance (Teil 7)

Was beeinflusst die SharePoint Performance (Teil 7)

image
Lieber Leser,

nach einer langen Pause möchte ich nun diese Serie weiter fortführen. Je “höher” der Layer, desto größer sind die Vorteile natürlich. WCM wäre ohne den Output Cache, auch Page Output Cache genannt, mit SharePoint nicht möglich. WCM und SharePoint wäre ein Blog-Thema für sich. Ich bin da sehr vorbelastet und habe auch eine Meidung dazu. Dass der Microsoft Partner of the year, welcher O365 verkauft, nicht auf SharePoint setzt,  erklärt vielleicht einiges. Alleine der Viewstate ist oft größer wie so mache Typo3 Seite. Solange man bei Forms-Entwicklung bleibt, wird WCM immer problematisch sein. Vielleicht gibt es ja mal eine App, welche SharePoint als Datenlayer verwendet. WCM mit SharePoint geht – wie fast alles mit SharePoint irgendwie geht. Für mich ist das Hauptkriterium, dass Google die Seite mag (Seitenaufbauzeit, schönes HTML..) . Ich warte schon auf einen Blog-Artikel, der einen Test hierzu liefert. Es gibt viele Artikel zu Tag-Navigation oder Cross Site Publishing, aber keinen hierzu. Schade. Nach neusten Studien ist der Faktor “Anständiges HTML” nicht mehr so wichtig: http://blog.searchmetrics.com/de/2012/02/09/die-google-ranking-faktoren-2012-fur-deutschland/
Grund genug sich mit dem Output Cache zu befassen!

Der Outputcache funktioniert nur mit Publishing-Seiten und ist standardmäßig nicht aktiviert:

image

Das macht auch Sinn, wie man gleich sehen wird. Gespeichert wird im Outputcache die komplette Webseite. Das spart den Weg in die darunterliegenden Layer, SQL Ressourcen und CPU für das Rendering. Implementiert wird der Output Cache über zwei IIS Module.

Da die Webseite in Abhängigkeit der Berechtigungen unterschiedlich ausschaut, muss es mehrere Versionen einer zwischengespeicherten Seite geben. Die Kriterien, welche den Schlüssel für diese “Cache-Version” erzeugen, werden in Profilen gespeichert:

imageimage

(Seitenaktionen->Webseitensammlungsverwaltung->Cachprofile für die..)

Diese Profile werden dann auf Site-Collection Ebene für anonyme- und authentifizierte Benutzer einem getrennten Profil zugewiesen. Darüber hinaus ist es auch möglich einer Webseite, einem Page Layout  oder Masterpage ein gesondertes Profil zuweisen:

image

Das macht z.B. dann Sinn, wenn ich eine Webseite habe, welche sich für einen großen Teil der Inhalte die “gleiche” Cache-Version verwenden soll, auf einer best. Seite(Masterpage, Layout etc.) müssen aber Benutzerprofilinformationen angezeigt oder gepflegt werden. Dann würde man dieser Seite eben ein anderes Cache Profil zuweisen. Mit einer kleinen Entwicklung, einem “Vary by Customer Parameter” könnte man auch eine Cache-Version für jeden Nutzer anlegen.

Bevor man den Cache aktiviert, solle man die Profile begutachten. Es gibt bereits vordefinierte, welche mit sinnigen Einstellungen angelegt wurden:

imageimage 

 

Einstellung Beschreibung
Titel Name des Profils (Öffentlich, Extranet etc.)
ACL-Überprüfung ausführen Legt fest, dass jede “Cache-Information”  mit einer ACL abgelegt werden. Macht in Kombination mit “

Unterscheidung nach Benutzerrechten” Sinn.

Aktiviert Wenn es Probleme damit gibt (dazu gleich mehr), kann es einfach deaktiviert werden. Da ein Profile an vielen verschieden Stellen aktiviert werden kann –  eine gute Einstellung.
Dauer Verweildauer: wie lange wird der Cache als gültig markiert, bevor die Version aus dem Cache entfernt/überschrieben wird.
Auf Änderungen überprüfen Ist der Haken deaktiviert, dann kann ggf. für die unter Dauer definierte Zeit ein Benutzer auf etwas zugreifen, auf das er vielleicht gar kein Recht mehr hätte. Da 180 Sek. aber nicht “die Welt” sind, würde ich ihn deaktivieren.
Unterscheidung nach HTTP-Headern Könnte man verwenden, wenn man für unterschiedliche Header reagieren möchte. Da man das am Client/Browser nicht wirklich beeinflussen kann, macht dies vermutlich nur in der Kombination mit einem Proxy Server, welcher zusätzlich Headerinformationen(für was auch immer) liefert.
Unterscheidung nach Abfragezeichenfolgeparametern Kann man z.B. verwenden wenn man für einzelne Benutzer eine eigene Cache-Version haben möchte. Mehr hier

Unterscheidung nach Abfragezeichenfolgeparametern

Die GET-Parameter sollten i. d. R. nicht von Bedeutung für das Caching sein.

Unterscheidung nach Benutzerrechten

Für authentifizierte Benutzer ist dieser Haken Pflicht . In einem Profil für anonyme Benutzer wird sie nicht benötigt.
Cachefähigkeit
image
Dem Client(Browser) und dem Proxy-Server(Apache, UAG, TMG) wird mitgeteilt, ob gecacht werden darf:
NoCache: Client und Proxy dürfen zwischenspeichern, müssen sich aber über eine Änderung informieren;
Private(Standard): Client darf speichern, Proxy nicht
Server: verhält sich wie NoCache(Control: no-cache)
ServerAndNoCache: verhält sich wie NoCache
Public: Alle dürfen zwischenspeichern. Das kann natürlich sehr gefährlich sein. Wenn der Proxy-Server anfängt, die Anfrage nicht mehr an SP zu senden, sondern die Seite direkt ausliefert. Ich habe schon bei einer falschen TMG Konfiguration gesehen, dass man OWA-Mails des Kollegen lesen konnte, da dessen Version von ISA ausgeliefert wurde. Für authentifizierte Benutzer ein NoGo! 
ServerAndPrivate:Response wird auf dem Server “gecacht”(eigentlich weniger – aber das sollte den Browser nicht interessieren), Browser darf zwischenspeichern, Proxy Server nicht.

image

Sicher für authentifizierte Verwendung

Schützt das Profil vor unsachgemäßer Verwendung. Ein Admin, welcher dieses Profil ggf. einem Page Layout zuweist, weiß ja nicht zwangsweise wie dieses Profil konfiguriert wurde.

Schreibern erlauben, zwischengespeicherten Inhalt anzuzeigen

Dieser Haken sollte immer gesetzt sein. Für jemand der bearbeiten darf, sollte immer die aktuelle Version ausgeliefert werden. Das Java-Script kommt ganz schön durcheinander, wenn der Haken deaktiviert ist. Bei einer Wiki-Seite, welche mit “[[“ erzeugt wird, wird die Seite generiert, im Anschluss aber nicht der Link auf der Quell-Seite erzeugt==> Chaos.

Die Cachefähigkeit werden wir in Kombination mit dem BLOB Cache noch einmal genauer beschreiben. Dort kann man nämlich auch festlegen, ob auf eine Aktualisierung (z.B von einem Bild) von Client-Seite überhaupt überprüft wird ob es eine neue Version gibt oder das Bild direkt aus dem Browser-Cache angezeigt wird. Damit kann man die Request-Anzahl reduzieren. Aber mehr dazu in BLOB-Artikel.

Hört sich soweit alles ganz gut an. Noch ein paar wichtige Anmerkungen:

Eine Änderungen einer Seite führt zum einem “Cache Flush” aller Seiten der Site Collection auf diesem Profil. D.h. bei klassischem SharePoint Nutzerverhalten kostet mich das Aktivieren der Outputcache Ressourcen und damit auch “unnötige” Performance.

Habe ich mehr als 10000 “unique” Berechtigungen (Breakroleinheritance auf Listen, Elemente- und Webebene), funktioniert der Cache nicht mehr. Man muss noch bedenken, dass in den beiden Papierkörben(Site Collection, Web) auch Elemente enthalten sind. Auf der DB muss hierfür folgendes Statement ausgeführt werden.

SELECT * FROM TVF_Perms_Site(‘SPSite.id)

Das 10.000 Limit kennen wir von vielen Sharepoint-Limits. Wenn mehr als 10.000 Zeilen zurückgeliefert werden, wird ein Table-Lock erzeugt, welcher die ganze Tabelle kurzzeitig auch für alle anderen lesenden Sitzungen blockiert. Das ist ein Unterschied zu Oracle, hier können lesende Operationen nicht andere lesende Operationen blockieren. Ich habe das mal getestet, konnte aber keinen Table-lock feststellen. Der default Isolation-Level wurde für diese Transaktion nicht angepasst (NOLOCK), deshalb war das etwas unerwartet, dass es kein Table Lock gibt(auch wenn man den Query-Hint der Funktion entfernt). Dennoch sind große Ergebnismengen für alle Datenbanken schlecht – für SQL jedoch besonders schlecht. Wer möchte, kann den Output Cache auch über die Web.config Konfiguration anpassen. Nachdem man den Cache aktiviert hat, ist es definitiv ratsam zu überprüfen, ob dieser auch funktioniert.

  • image

    Danach wird in der letzten Zeile des Source Codes eine Information ausgegeben:

    image

    Man sieht welches Profil geladen wurde und zu welcher Uhrzeit die Version erstellt wurde. Es sollte definitiv darauf geachtet werden, dass die Version für die Cache-Lifetime( Dauer) auch bleibt. Es gibt mehrere Gründe, warum ggf. bei jeder Anfrage eine neue Version erzeugt wird:

    1. .Net Patch http://support.microsoft.com/kb/2638420
    Nach diesem Patch wird bei jedem Response ein Cookie angefügt und der Cache funktioniert nicht mehr;

    2. Entwicklung, die ein Cookie in den Response hängt;

    3. Dezember 2010 CU (SharePoint 2010)

    Danach funktioniert der Cache für authentifizierte Benutzer auch nicht. Naja CUs – ein spezielles Thema. Wer ein CU direkt nach Veröffentlichung installiert, geht aber definitiv grob Fahrlässig mir der Farm um.

    4. Wenn “Auf Änderungen überprüfen” oder “ACL-Überprüfung ausführen” aktiv sind, wir bei jeder Änderung (SPSite.LastContentModifiedDate) der Cache für ALLE Seiten geleert. Für Kollaboration mit authentifizierten Benutzern ist dieser Cache eine Bremse.

    Ein iisreet löscht den Cache natürlich auch.

     

    Fazit: Für den Webauftritt mit anonymen Usern ist der Output Cache ein muss! Wer klassisches SharePoint Userverhalten lebt, der sollte diesen Cache nicht aktivieren. Es gibt zu viele Bedingungen, die zu einem Neuaufbau des Cache führen. Dass der Cache bei einem Update eines beliebigen Elementes für jede Seite neu aufgebaut werden muss “nervt”. Wenn man aber bedenkt, dass in einer Wiki-Seite ggf. Listen, SearchResults, Ergebnisse von Webparts aus Webservices etc. angezogen werden, dann ist es auch technisch gar nicht so einfach ein “Update” der Seitenausgabe mitzubekommen.

    Sonstige Anmerkungen

    Vor ein paar Wochen war ich auf einem Vortag zu Azure IaaS. Meine Meinung: zu teuer im Vergleich mit Profitbricks, Cloudsigma & CO. Wer die VM ausschaltet bezahlt trotzdem für CPU und RAM. Man muss die VM erst exportieren, danach löschen und wieder importieren. Was für ein Aufwand! Ob eine VM ausgeschaltet ist oder nicht, kann auch eine Microsoft feststellen. Man könnte es auch “Abzocke” nennen. Ich bin inzwischen wieder bei Hardware von Hetzner. Eine SharePoint Maschine im “Leerlauf” mit allen Rollen + SQL benötigt ohne offene Apps, Visual Studio etc. bereits 16GB RAM:
    imageimage

    Gut – wer weniger RAM hat, wird SQL beschränken, damit genügend Luft vorhanden ist. Mit SSD und echter Hardware hat man dann eben eine Performance, die wirklich Spaß macht! Hardwareschäden werden innerhalb von 2h ersetzt – für mich ist das okay.

    Was mich an diesem Vortag aber wirklich gestört hat: “Auf 2 Azure VMs kann man 10.000 aktive Kollaborations-User bedienen”. Hoffentlich bekommt so eine Aussage kein Kunde in den Hals! So ein Schwachsinn.

    Es ist sehr wichtig, dass man die Limits von SharePoint kennt. Mein Kollege Jochen Funk, mit dem ich gerade an einem spannenden Projekt tüftele, wird auf dem ShareCamp in München einen Vortrag hierzu halten. Ich kann leider nicht zuhören – bin in Arizona.

    Am Do. 7.3 bin ich auf der Cebit um mir die Stände von Microsoft, Alfresco, IBM  & Co. anschauen.  Dann gibt’s den nächsten Post. Ich werde diese vergleichen, die Unterschiede aufzeigen und natürlich wieder meinen Senf dazugeben Smiley.

    Ich wünsche gute Hardware, einen schnellen SharePoint & Freundliche Grüße,

    Tobias Wolter

  • One thought on “Was beeinflusst die SharePoint Performance (Teil 7)

    1. Pingback: SharePoint 2013 Nuggets of the weeks 5,6,7,8 and 9 - Ragnar Heil: SharePoint Nuggets - Site Home - MSDN Blogs

    Hinterlasse eine Antwort

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

    Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>