Schnellere SharePoint 2010 Entwicklungs- und Demo-Umgebungen

Wir alle kennen dieses Problem seit langem: Die SharePoint Entwicklungs- oder Demo-Umgebung läuft auf einer (oder mehreren) virtuellen Maschinen und ist zum Teil nervig langsam. Die HD-Lampe hört meistens kaum mehr zu leuchten auf und auch die CPU ist oft fast ständig über 50%.

Dies ist natürlich ein grundsätzliches Problem, denn SharePoint -Entwicklungbenötigt seit anhin viele Ressourcen: Visual Studio & Toole, Datenbanken, ActiveDirectory, Services usw. Meist muss da schon eine sehr rechen- und RAM-starker Entwicklungsmaschine vorhanden sein um "vernünftig" entwickeln zu können. Und selbst dann: Mit RAM und schnellem Prozessor ist es immer noch nicht gemacht.

Speziell bei SharePoint 2010 habe ich die Erfahrung gemacht, dass folgende Faktoren entscheidend die Performanz beeinflussen:

• Rechenleistung, RAM & Festplatten-Grösse
• Unnöltige Services sind am Laufen
• Es wird zu viel geloggt.

Im Folgenden möchte ich deshalb kurz auf die einzelnen Punkte eingehen und meine Verbesserungsvorschläge einbringen. Ich gehe dabei nicht auf die optimierung von virtuellen Rechnern im allgemeinen ein sondern nur ein paar Tipps für die Entwicklung unter SharePoint 2010:

Rechenleistung, RAM & Festplattengrösse

Für eine schnelle SharePoint 2010 Umgebung braucht es auf jeden Fall eine moderne und leistungstarke CPU, mindestens 4 Cores sind angebracht.

Beim RAM empfehle ich zwischen 2.5 und 6 GB, aber es kommt v.a. darauf an, ob der SQL Server auf derselben Maschine läuft oder nicht. Wenn ja, dann muss dieser so konfiguriert werden, dass er nur bis zu einer Limite (bei mir reichen 500MB meistens aus!) RAM verwenden darf! Dies kann im SQL Management Studio in den Eigesnchaften der Instanz konfiguriert werden. Auch die einzelnen Application Pools konfiguriere ich so, dass sie sich ab einem bestimmten Speicher-Bedarf selber recyclen (dies kann im IIS in den erweiterten Eigenschaften des Application Pools eingestellt werden). Der SharePoint Health Analyzer generiert dafür zwar eine Warnung - mit der kann ich aber gut leben, da ich so sicher bin, dass mir z.B. ein Application Pool für einen Web-Service nicht alles RAM "auffrisst".

Bezüglich der Festplattengrösse ist aus meiner Sicht v.a. zu beachten, dass die System-Partion immer genügen Platz für das Paging-File hat. Fixe virtuelle Hard-Disks sind zudem aus meiner subjektiven Sicht schneller als dynamisch wachsende.

Unnötige Services / Service Applications

SharePoint 2010 kommt mit einer Unmenge an Services und wenn man SharePoint über den Standard Setup installiert, werden alle Services mit den dazugehörenden Service Applications und -Proxies installiert und gestartet. Dies generiert nicht nur eine stattliche Anzahl an Datenbanken sondern auch viele (unnötig) laufende Services, welche Rechenleistung und Disk-IO verbrauchen.

Entscheiden sind hier v.a. die Search Services: Windows Foundation Search und Enterprise Search laufen meistens gemeinsam, was an sich schon falsch ist. Ist die Enterprise Search sauber aufgesetzt wird die Foundation Search nicht benötigt. Aber viel wichtiger: Die Search Services sind mit Abstand am meisten für die generell hohe Disk-IO verantwortlich (Indezierung usw.). Entwickelt man also nicht gerade für die Suche können diese Services getrost abgeschaltet werden!

Was kann man tun:

• Unnötige Windows Services abschalten respektive auf manuelles Starten setzten: "Spooler","AudioSrv","TabletInputService"
• Alle nicht benötigten Service Applications respektive -Proxies löschen (diese können jederzeit neu erstellt werden)
  • Central Administration --> Application Management--> Manage Service Applications
  • Folgende Services sollten mindestens beibehalten werden: State Service, Security Token Service, Application Discovery und Load Balancer Service Application, Usage and Health Data Collection sowie allenfalls der Secure Store Service
• Nachdem die Service Applications entfernt wurden, können die nicht benötigten Services gestoppt werden
  • Central Administration --> Application Management--> Manage Services on Server
  • Nicht gestoppt werden sollten: Central Administration, Microsoft SharePoint Foundation Web Application, Microsoft SharePoint Foundation Workflow Timer, Search Settings and Site Query Service sowie natürlich alle zusätzlichen Services, für welche eine Service Application besteht.

Logging reduzieren

SharePoint 2010 loggt sehr exzessiv: In die ULS Logs, in .Usage Dateien und neu auch in eine spezielle Datenbank, welche zur "Health and Usage Data collection" Service Application gehört. Gerade in diese Datenbank, aber auch auf das File-System wird sehr viel geschrieben, was natürlich die Disk-IO beeinträchtigt. Hier sollte man die Konfiguration genau prüfen und so wenig wie nötig loggen - die Einstellungen können ja jederzeit wieder angepasst werden:

• Central Administration --> Monitoring --> Configure Diagnostic Logging
  • Hier sollte das "Event Throttling" eingesetzt werden. Generell selektiere ich alle "All Categories" und setzte dann "Warning" für "Least critical event to report to the event log" und "High" für "Least critical event to report to the trace log"
  •  TraceLog: Mir reicht meistens, dass die Log-Files 2 Tage aufberwart beleiben.
• Central Administration --> Monitoring --> Configure Usage and Health Data Collection
  • In der Regel interessieren die Health und Usage informationen während der Entwicklung nicht. Deshalb können folgende Optionen abgestellt werden:
    • Enable usage data collection
    • Enable health data collection
  • Man kann aber auch granularer Vorgehen und z.B. die Periodizität anpassen, in denen die TImer-Jobs die Informationen verarbeiten.

Dies sind sie nun, meine persönlichen Tipps & Tricks zur Verbesserung der Performanz von SharePoint 2010 Entwicklungsumgebungen. Gerne nehme ich weitere (Verbesserungs-)Vorschläge entgegen und führe sie in diesem Blog-Beitrag zusammen!

Kommentar

Kommentar hinterlassen Name: Email: Ihre URL: Kommentare: Sicherheitscode eingeben: