Als sich das IIS-Team von Microsoft den Begriff „Webgarden“ ausdachte, wollte es damit ausdrücken, dass es sich hier um etwas Ähnliches wie eine „Webfarm“ in klein handelt. Die Farm bezeichnet die Verteilung von Webanfragen auf mehrere Webserver, der Garten verteilt die Last auf verschiedene Prozesse einer Server-CPU.
Tatsächlich hieß die Einstellung dafür nur in IIS 6 „Webgarden“, ab der Version 7 findet man sie unter „Maximale Anzahl von Arbeitsprozessen“. Nur noch der erklärende Text dazu im unteren Fensterbereich erwähnt das Wort „Webgarden“.
Wenn als maximale Anzahl mehr als 1 Prozess erlaubt ist, hat man einen Garten.
Will man diesen Garten anlegen oder wächst dort nur Unkraut?
Vorteil bzw. einziger Anwendungsfall:
Webgarden kann die Performance verbessern, indem Web-Apps mit geringer CPU-Auslastung, aber lange dauernden Requests (z.B. aufwändige Datenbankabfragen), auf mehrere Prozesse verteilt werden, sodass sie nicht alle verfügbaren Threads des einzigen Arbeitsprozesses für sich in Anspruch nehmen.
Das ist das Szenario, in dem Webgarden einen Versuch wert ist. Einzig für diesen Fall wurde dieses Feature entwickelt. Webgarden ist nicht als eine Art Standard-Load-Balancer auf CPU-Ebene gedacht, den man immer aktiviert, wenn CPUs mit mehreren Kernen vorhanden sind.
Performanceschwierigkeiten verlangen jedoch häufig nach gründlicheren Lösungen. Zudem hat der Betrieb eines Webgardens einige Nachteile, welche dem eventuellen Gewinn an Geschwindigkeit gegenüberstehen.
Nachteile:
Multiplikation von Speicherinhalten
Webgarden vervielfältigt den immer gleichen Speicherinhalt für jeden weiteren Prozess. Eine Datenbankabfrage würde nicht nur in einen cache geschrieben, sondern in den cache von jedem einzelnen Prozess. Die myfactory beansprucht damit ein Vielfaches dessen, was sie von dieser Ressource eigentlich nur benötigt.
InProc Session State funktioniert nicht
Dieser InProc Modus, also das Halten des Session State im Speicher des Prozesses, ist die Voreinstellung und die übliche web.config von myfactory ändert daran nichts.
Für die Webfarm gibt es Sticky Sessions, die dafür sorgen, dass z.B. über Cookies identifierte Nutzer im Verlauf ihrer Session immer mit demselben Server interagieren. Der Webgarden garantiert hingegen überhaupt nicht, dass die Anfragen einer Quelle immer im selben Worker Process bleiben. Prozessgebundene Session States würden also verloren gehen.
InProc Session State ist zwar die Voreinstellung in dem Sinne, dass eine web.config ohne Einträge dazu diesen Modus aktiviert, aber ASP.NET bietet Alternativen zum prozessgebundenen Session State.
State Server Mode: Speichert die Informationen über die Session in einem separaten Process außerhalb des App Pools. Damit wird der Session State erhalten, auch wenn die Web-Anwendung neu gestartet wird oder die Webserver während der Session wechseln. Der State Server verlangt dann einen eigenen Connection String und der Eintrag in der web.config sähe beispielhaft so aus:
SQL Server Mode: Sichert den Session State durch Speichern in einer Datenbank. Dies verlangt ebenfalls einen Connection String und der Eintrag in der web.config sähe etwa so aus:
Daneben gibt es noch den Custom Mode, in dem sich ein eigener Provider für die Informationen zum Session State definieren lässt und OFF, was das Session State Management komplett ausschaltet. Den Custom Mode werden wir kaum benötigen, das Abschalten könnte zu Testzwecken nützlich sein. Der entsprechende Eintrag wäre:
Fehlersuche wird komplizierter
Bei Webanwendungen folgt der Debugger dem Arbeitsprozess. Wenn es davon mehrere gibt, ist es nicht leicht zu erkennen, an welchen der w3wp-Prozesse der Debugger anzuhängen ist.
SignalR funktioniert nicht mehr ohne Weiteres
Anwendungen wie unser myfactory.FON-Modul, die SignalR für Benachrichtigungsfunktionen nutzen, würden ohne weiteres Zutun im Webgarden nicht funktionieren. Diese Technologie verträgt sich nicht mit wechselnden Servern im Falle der Webfarm oder mit auf Prozesse verteilte Requests im Webgarden. Ein SignalR Broadcast an alle Clients würde nur diejenigen erreichen, die mit dem den Broadcast aussendenden Prozess verbunden sind.
Die myfactory setzt Cookies und speichert ansonsten alles in der Datenbank. Deshalb ist das im Standard unproblematisch. Erweiterungen, die wie das Zusatzmodul zur Telefonie SignalR nutzen, sollten sich aber besser nicht im Webgarden verirren. Es gibt jedoch Möglichkeiten, SignalR sicher durch den Garten zu führen. Sie ersetzen alle den Message Bus von SingalR durch einen neuen.
Azure Service Bus. Die Microsoft Cloud kann sich darum kümmern. Das erlaubt fast grenzenlose Skalierung, ist jedoch für myfactory ein wenig übertrieben.
Redis. Die kleine NoSQL-Datenbank im Hauptspeicher ist die performanteste Lösung.
SQL Server. Der SQL Server speichert die Nachrichten in Tabellen auf der Festplatte und ist damit natürlich etwas langsamer als Redis. Ein Service Broker sorgt für eine effiziente Abarbeitung der Nachrichten, für den Betrieb nötig ist er jedoch nicht.
Das myfactory.FON-Modul bietet Redis und den SQL Server als Lösungen an.
Ist der Webgarden für myfactory sinnvoll?
Ohne Not über den Einsatz des Webgardens nachzudenken, ist sicher nicht sinnvoll. Eine Web-App, deren Performance okay ist, braucht kein Tuning. Wenn sie zu behäbig reagiert, stellt sich die Frage, ob die Problemursache zum Anwendungsszenario des Webgardens passt, also lange Requests bei gleichsam geringer CPU-Auslastung entstehen.
Bremsen zu lange Requests die myfactory aus?
Zur Beantwortung dieser Frage ist etwas Monitoring nötig. Das Feature „RequestMonitor für IIS“ ist nicht standardmäßig verfügbar. Es lässt sich über die Feature-Auswahl „Windows-Features aktivieren oder deaktivieren“ hinzufügen. Am schnellsten geht das aber in Power Shell mit folgendem Kommando:
Danach ist diese Monitoring-Funktion auf der Konsole im Verzeichnis C:\Windows\System32\inetsrv sowie im IIS-Manager einsatzbereit. Der Folgende Screenshot zeigt beispielhaft einen Request von myfactory, angezeigt in CMD.
Kommando:
Ausgabe:
Im IIS-Manager öffnet sich die Anzeige der Requests über das Kontextmenü des Prozesses:
Finden sich hier keine Requests, die einige Sekunden lang dauern, dann ist es auch nicht nötig, sie auf mehrere Prozesse zu verteilen. Wenn es sie jedoch gibt, lohnt es sich, Webgarden auszuprobieren – schon allein als Analysetool, selbst wenn am Ende vielleicht aufgrund der Nachteile die Entscheidung gegen den Dauereinsatz fällt. Bei dieser Abwägung ist zu fragen, ob myfactory überhaupt von den Nachteilen betroffen ist.
Sind die Nachteile des Webgardens für myfactory von Bedeutung?
Die Multiplikation von Speicherinhalten betrifft natürlich auch myfactory.
Session States benötigt die myfactory nicht, weil sie auf Cookies setzt und sonst alles in die Datenbank schreibt. Für Erweiterungen des Standards könnte aber an dieser Stelle ein Mehraufwand durch Webgarden entstehen. Außerdem kann es auch nicht vollkommen ausgeschlossen werden, dass nicht doch irgendwo im Standard einmal ein InProc Session State verwendet wird.
Ein Debugging unter realistischen Bedingung, d.h. mit den gleichen IIS-Einstellungen wie im Echtsystem beim Kunden wird verkompliziert, wenn nicht gar unmöglich gemacht, denn IIS auf Client-Systemen hat auch noch eine Limitierung bei den möglichen Arbeitsprozessen, sodass sich das Produktivsystem vom Server eventuell auf dem Client, auf dem Visual Studio läuft, überhaupt nicht nachbilden ließe.
Für das SignalR-Problem sind für das FON-Modul bereits zwei Lösungen implementiert. Für jede weitere Erweiterung, die SignalR nutzt, ist das jedoch immer zu berücksichtigen.
Fazit
Erfahrungsgemäß kommen im Betrieb der myfactory durchaus gelegentlich große Requests vor, die zu Wartezeiten führen können. Wenn dies festgestellt wurde und die CPU noch Reserven dafür hat, ist der Webgarden mindestens zur Analyse der Performance ein lohnenswertes Instrument. Wenn sich der Unterschied als messbar positiv herausstellt, ist ein Dauerbetrieb unter Berücksichtigung der Komplikationen denkbar. Den Webgarden einfach deshalb zu betreiben, weil die CPU mehrere Kerne hat, ist aber sicher der falsche Ansatz.
.svg)
.svg)
