Seiwert GmbH
Fernwartung
  • Startseite
  • Informationen
  • Aktuelles
  • Aktuelles Detail
Leistungen
Beratung

Beratung

Gemeinsam die passende Lösung finden und entwickeln

Beratung

Projekt

Wir begleiten Sie durch die gesamte Phase der Projektentwicklung und -umsetzung

Beratung

Betreuung

Wir betreuen Sie auch nach Abschluss Ihrer Projekte

Beratung

Schulungen

Unsere Schulungen für die myfactory Welt

Lösungen
myfactory

myfactory

Alles Wichtige zur myfactory auf einen Blick

ERP, CRM, ECO, FMS, PPS, HRM, MIS, POS
shipXpert

ShipXpert

Für eine effiziente Versandabwicklung

shopware

Kreiere das Außergewöhnliche

  • Zusatzmodule
    • CRM
    • E-Commerce
    • ERP
    • PPS
    • Schnittstellen
    • Scanner
Informationen
myfactory

Aktuelles

Neuigkeiten & Wissenswertes

ELO

myfactory eLearning

Videos zu den Neuerungen rund um die aktuellen Servicepacks

ELO

myfactory Online-Hilfe

Online Dokumentation der myfactory-Software

Aktuelles

FAQ

Fragen und Antworten rund um die myfactory und Technik

Über uns
Team

Unternehmen

Wer wir sind und was wir machen!

Team

Team

Erfahren Sie mehr über das Team der Seiwert GmbH

Referenzen

Referenzen

Das sind unsere Kunden

Jobs

Jobs

Sind Sie auf der Suche nach neuen Herausforderungen?

Blog

Blog

Regelmäßige Informationen um die myfactory und Seiwert GmbH

Kontakt
Telefon

Zentrale

Rufen Sie uns an!
+49 69 175 3637 0

Support

Support-Hotline

Sie benötigen technische Unterstützung?
+49 69 175 3637 50

E-Mail

Support E-Mail

Sie benötigen Unterstützung? Schreiben Sie uns unter support@seiwert.info

Kontaktanfrage

Kontaktformular

Nehmen Sie bequem über unser Kontaktformular Verbindung auf!

Fernwartung
AnyDesk

AnyDesk

AnyDesk Client Download für

Windows

und

MacOS
Registrieren
Anmelden
Schließen


Angemeldet bleiben
Passwort vergessen?
Bitte geben Sie ihre E-Mail Adresse an.
Wir senden Ihnen einen Link zum Zurücksetzen des Passworts.

Webgarden: IIS mit mehreren Arbeitsprozessen

Zurück
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.
 
Webfarm und Webgarden
 
 
 
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“.
 
Einstellungen IIS
 
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:
 
State Server Mode
 
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:
 
SQL Server Mode
 
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:
 
Custom Mode
 

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.
 
myfactory Konfiguration Webgarden
 

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:
 
Feature Request Monitor in der PowerShell aktivieren
 
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: 
 
Request von myfactory
 
Ausgabe:
 
Request von myfactory. Ausgabe in CMD
 
Im IIS-Manager öffnet sich die Anzeige der Requests über das Kontextmenü des Prozesses:
 
 
IIS Manager mit Kontextmenu 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.
 
  • Leistungen
  • Lösungen
  • Zusatzmodule
  • Schulungen
  • Informationen
  • Über uns
Twitter Facebook Xing LinkedIn myfactory Zertifizierter Partner
Zentrale anrufen
+49 69 175 3637 0
Support-Hotline
+49 69 175 3637 50
Support E-Mail
willkommen@seiwert.info
  • Impressum
  • Datenschutz
  • AGB