Torsten Flegel

So endlich mal zu den Maßnahmen die man zur Perfomanzsteigerung durchführen kann. Ich gliedere das mal in zwei Bereiche, denn es gibt allgemeine Tips und einen speziellen für ein weit verbreitetes Problem:

Problem:

Die SharePoint – WebSeiten dauern beim ersten Aufruf extrem lange – auch der Aufruf von stsadm ohne Parameter in der Kommandozeile hält  20-30 Sekunden inne bevor die Hilfe erscheint. Während man auf die Webseiten warten ist keine Last auf dem Server, er scheint nichts zu tun.

Lösung:

WarmUp Scripte beheben nur das WebSeiten Problem aber nicht die Ursache (wozu WarmUp Scripte dennoch gut sind, siehe unten bei allgemeine Tipps). In diesem Fall ist die Ursache für das Problem aber das das .Net Framework beim Laden von signierten DLLs aus dem GAC in Internet in einer “Certificate Revocation List” (unter  crl.microsoft.com) nachschaut. Ach in dem Fall das die Signatur dort unbekannt ist (und das ist ja bei Eigenentwicklkungen die Regel), wird die DLL geladen und funktioniert auch.
Da Server meistens keine Internet-Verbindung haben, kommt dieses Problem leidlich oft vor.

BTW: Natürlich steht keine Fehlermeldung, Warnung oder Information im EventLog – wäre ja auch zu einfach

Dieses Standardverhalten hängt an einem Registry Wert der leider für jeden Nutzer einzeln zu setzen ist – und zwar auf folgenden Wert:
[HKEY_USERS\<userid>\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing] “State”=dword:00023e00

Ein andere Methode die Überprüfung auszuschalten  ist natürlich seinen Servern den Zugriff auf  crl.microsoft.com zu gestatten, allerdings ist das häufig aus Sicherheitsgründen unmöglich.

Für die stsadm Wartezeit ist eine einfache Lösung eine stsadm.exe.config Datei in bin-Verzeichnis des 12Hive zu legen, welche folgenden Inhalt hat:

<?xml version=”1.0″ encoding=”utf-8″?>
<configuration>
<runtime>
<generatePublisherEvidence enabled=”false”/>
</runtime>
</configuration>

Hinweis: Diese Probleme können auch beim SQL-Server auftreten, sofern mittels .Net um Funktionen erweitert wurde.

Allgemeine Tipps:

1. IIS Compression bzw. GZIP Kompression

Wenn man sich die Dateien insb. die core.js und andere JavaScript Dateien des SharePoint ansieht, weiß man das hier einige 100 KB unnötig die Leitung passieren. Um dem Abhilfe zu schaffen sollte man die IIS Komprimierung einschalten, für IIS 6 und Windows 2003 geht das folgender Maßen:

–>zuerst die Dateitypen hinzufügen, einmal für die statischen Inhalte .

CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/DEFLATE/HcFileExtensions “htm” “html” “txt” “css” “js”

CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/GZIP/HcFileExtensions “htm” “html” “txt” “css” “js”

und dann für die dynamsichen:

CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/DEFLATE/HcScriptFileExtensions “asp” “exe” “axd” “aspx”

CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/GZIP/HcScriptFileExtensions “asp” “exe” “axd” “aspx”

–> Schließlich noch das Kompressionslevel (1-10) angeben:

CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/DEFLATE/HcDynamicCompressionLevel “9”

CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/GZIP/HcDynamicCompressionLevel “9”

Für IIS 7 und weitere Infos empfehle ich hier den BLOG-Eintrag von Andrew Connell.

2.  Noch schneller ist freilich die core.js nur zu laden wenn sie wirklich benötigt wird und anonyme Nutzer brauchen sie normalerweise gar nicht – siehe hierzu http://support.microsoft.com/kb/933823 und Small Page Good Page MSDN Artikel.

Oder besser noch mit JQuery einfach beliebige JavaScript-Dateien asynchron laden. (Gefällt mir am besten )
3. SharePoint Caching – dazu muss man glaube ich nicht mehr viel sagen, am besten folgenden MSDN Artikel nehmen.

4. WarmUp Skripte: da hat sich seit Joel Oleson’s ursprünglichen WarmUp Skripts einiges getan, und schließlich als SPWakeUp auf CodePlex weiter entwickelt.

5. Die Seitengröße: Immer ein gutes Mittel die Sweiten schneller auszuliefern, ist freilich ihre Größe zu überprüfen – abseits von JavaScript Dateien findet man oft genug andere Medien die zuviel KB auf dem Buckel haben. Tools zur Analyse gibt es eine Menge: z.B. Page Speed von Google (ein FireBug PlugIn) oder auch Fiddler PlugIn names neXpert Perfomance Tool.

6 . Letzer kleiner Hinweis nochmal das Dispose checker tool: das Tool hatte ich auf dem BLOG scho vor einer Zeit mal erwähnt:  http://code.msdn.microsoft.com/SPDisposeCheck –> es hilft Speicherlöcher in eigenen Entwicklungen aufzuspüren.

Sicherlich gibt es noch eine ganze Menge an weiteren Hinweisen, aber für einen ersten Überblick sollte das reichen…

Quellen: Marwan Tarek, Muhimbi