Sharepoint, IIS, .net und Multithreading

Question

Ich bin mir bewusst, dass IIS für Multithreading als Standard konfiguriert ist. Ich habe Leistungsprobleme mit meinen Webservern, die Sharepoint 2007 hosten.

Also meine Frage ist;

Verwendet Sharepoint 2007 Multithreading als Standardlösung oder sind es nur Anpassungen mit .net?

Und weiß jemand, wie ich Benutzer begrenzen könnte mehrere Threads/Verbindungen auf einer Server-Admin-Ebene (IIS) oder würde dies einen negativen Einfluss auf Anwendungen oder Website in Sharepoint?

Dank

Answer 1

SharePoint-Leistungsprobleme sind ein komplexes Thema. Sie müssen nach Fehlern suchen, um festzustellen, wo Sie Leistungsprobleme haben. Ist es die Webfarm? Das Datenbank-Backend? Haben Sie einen Webpart, der Probleme verursacht? Leistungsmonitor ist ein guter Anfang.

Und um Ihre Frage zu beantworten, ob SharePoint Multithreading verwendet? Ja, in dem Sinne, dass es auf IIS und ASP.NET aufbaut. Es ist in keiner Weise verkrüppelt.

Answer 2

Ich glaube wirklich nicht Threading verursacht Perf-Probleme, die Sie erleben.

Answer 3

Um die "einfache" Frage in Ihrem Beitrag zu beantworten, werden SharePoint-Websites über ASP.NET bereitgestellt. Das heißt, Sie haben über das processModel Element, das sich innerhalb der machine.config auf jedem Ihrer SharePoint-Webfrontends (WFEs) befindet, umfassende Kontrolle über das Threadingmodell/-management von ASP.NET. Sie können sowohl für den Worker-Prozess als auch für die E/A-Vorgänge minimale und maximale Anzahl von Threads festlegen. Darüber hinaus stehen eine Reihe weiterer Einstellungs-/Optimierungsoptionen zur Verfügung. Weitere Informationen finden Sie auf der Microsoft-Website unter http://msdn.microsoft.com/en-us/library/7w2sway1.aspx.

Mit dem gesagt, ich kann Martin nicht mehr zustimmen: Performance-Fehlersuche in SharePoint ist selten ein Szenario "die Kugel finden". Wenn Sie die größeren "allgemein bekannten" WFE IIS/ASP.NET-Elemente angesprochen haben (in Joel Olesons Blog ziemlich gut zusammengefasst: http://blogs.msdn.com/joelo/archive/2007/10/29/sharepoint-app-pool-settings.aspx), dann sollten Sie unter normalen Anwendungsszenarien allgemein in Form sein. Danach beginnt das tiefere Graben.

Ich verbrachte den besseren Teil von sechs Monaten mit einem funktionsübergreifenden Escalation-Team von Microsoft zur Behebung von Leistungsproblemen für einen Client, und wir berührten fast alles: IIS/ASP.NET-Leistung, Effizienz von benutzerdefiniertem Code, Caching, Arbeitsspeicher Auslastung, Datenbankperformance, Webserviceleistung, Objektverfügung ... die Liste geht weiter und weiter. In jedem Schritt erfassten wir Speicherauszüge, nahmen quantitative Leistungsmessungen vor, beobachteten Leistungsindikatoren usw. Wir fanden mehrere Bereiche, die wir am Ende abstimmten, aber diese Bereiche wurden nur durch systematische Analyse und quantitative Messung gefunden.

Um ehrlich zu sein, empfehle ich nicht, Änderungen an einer der Konfigurationseinstellungen (wie processModel Einstellungen) ohne eine Arbeitshypothese und einen Performance-Tuning-Plan, der gute Messung und Vergleich enthält. Performance-Tuning ist generell nicht das, was man "Augapfel" nennen kann.

Auf der anderen Seite, kann eine Änderung der Einstellung oder zwei hier und da können Sie das Problem ein wenig zu stochern, wenn Sie starke Vermutungen haben - vorausgesetzt, Sie kehren zu Ihrer Grundlinie nach und tun dies auf eine Weise, die doesn Auswirkungen auf Ihre Benutzer/Kunden ...Aber auch ohne eine Möglichkeit, die Leistung vor und nach dem Wechsel quantitativ zu messen, können Sie keine spürbaren Unterschiede feststellen.

Viel Glück!