Performance-Optimierung

SMACC basiert auf der NET-Technologie und weist daher auf allen Plattformen ein gutes Performance-Verhalten auf. Damit meinen wir insbesondere die Abarbeitung rechenintensiver Prozesse und die Antwortzeiten der SMACC-Website. Bei den aktuell verfügbaren Servertechnologien arbeitet die Website Anfragen innerhalb 50-200 ms ab. Dies ist eine kaum spürbare Verarbeitungsdauer. Bei virtualisierten Webservern und bei Aktivierung von HTTPS können die Verarbeitungszeiten etwas höher liegen (bis max. 300 ms), was aber in den meisten Fällen auch kaum wahrgenommen wird. Dies ist auch wesentlich davon abhängig, wieviel CPU-Zeit die SMACC Website erhält.

Über das Thema Performance muss nachgedacht werden, wenn mit einer hohen Anfragelast auf der öffentlichen Website zu rechnen ist. Die Antwortzeiten werden zunächst bei nicht ausgelastetem Zustand des Servers gemessen. Sie erhöhen sich wenn Anfragen bei Belegung der sogenannten Worker-Prozesse warten müssen, oder mehrere Worker-Prozesse durch sequenzierte Datenbanktransaktionen pausieren müssen. Dies tritt statistisch erst dann ein, wenn eine bestimmte Anzahl von Nutzern-Sitzungen gleichzeitig Anfragen generieren und nicht mehr überwiegend auf den Leerlaufzustand treffen.

Ein Beeinträchtigung ist aber erst dann wahrzunehmen, wenn durch die Sequenzierung erhebliche Verzögerungen eintreten. Im allgemeinen geht man davon aus, dass bei einfachen Seitenaufrufen 1s als Latenzzeit ein ausreichender Wert ist. Bei Auslösung von Transaktionen, bei denen Nutzer mit einer höheren Verarbeitungsleistung rechnet, werden auch höhere Latenzzeiten akzeptiert (bis 10 s).

Sie sollten die Faktoren kennen, die zu einer hohen Anfragelast führen. Dies sind insbesondere:

• globale Portale
• begrenzte Verfügbarkeit von Produkten, wodurch sich die Anfragelast viele Kunden auf den Zeitpunkt der Freischaltung konzentrieren könnte.
• komplexe Produktstrukturen mit hohem Persistenz- und Validierungsaufkommen

Die Performance von NET-Anwendungen ist i.d.R. besser als vergleichbare mit Interpretertechnologien realisierten Anwendungen wie z.B. PHP. Der Hauptgrund besteht im Ansatz von NET-basierten Webbapplikationen und Webservices, welche kompiliert im Speicher verbleiben und somit bei eingehenden HTTP-Anforderungen sofort betriebsbereit sind.

Zudem bietet SMACC weitere Maßnahmen, um das Performance-Verhalten Ihrer Website auch in kritischen Einsatzfällen zu sichern:

• Applikations-Cache
• Optimierungen der Webseite
• Verwendung von Servicepools
• Integriertes Last-Monitoring und Abwehrmaßnahmen
• Optimierung von Validierungs- und Autorisierungsfunktionen
• Auslagerung von Verarbeitungsleistung in Hintergrundprozesse

Im folgenden erhalten Sie weitere Informationen über die einzelnen Möglichkeiten.

Im Applikations-Cache können häufig abgefragte Objekte oder Auflistungen gespeichert werden. Damit werden Datenbankabfragen und das OR-Mapping eingespart. Die Latenzzeit des Seitenaufbaus wird niedriger und die Arbeitslast des Servers sowie des Datenbanksystems verringert.

Der Applikations-Cache ist Bestandteil der Website. Durch ein Neustart der Website wird der Applikations-Cache gelöscht. Im Normalfall hat der Cach keine Auswirkungen auf die Funktion von SMACC, weil ein entsprechende Invalidierung existiert (Ungültigerklärung von Cache-Objekten). 

Die Cache-Unterstützung 

• Dynamischer Cache
• Statischer Cache: Der statische Cache besitzt keine integrierte Invalidierung. Dadurch wird zusätzlich Serverlast eingespart, weil die Invalidierung auch Rechenzeit benötigt. In ihm werden nur Objekte abgelegt, die äußerst statisch sind, d.h. sich nicht oder nur in großen Zeitabständen ändern. Die Invalidierung wird hier durch Neustart der Webapplikation(en) vorgenommen. Beispiele für relativ statische Objekte sind:
  • Anbieter (installierte Softwaremodule)
  • Länderliste
  • Währungsliste
  • Steuerzonen und Steuersätze

Unter Optimierungen der Webseite werden Optimierungen der HTML/ASP.NET-Komponenten in der Webapplikation verstanden. Diese Optimierung dient der Entlastung des Seitenaufbaus in der Webapplikation und der Verringerung des Seiten-Download-Volumens. Dies kann durch folgende Maßnahmen erreicht werden: 

• Verwendung Frame-Webs/ Inner-Frames
• Serverseitige Cache-Mechanismen für HTML
• Entfernung nicht benötigter oder unsichtbarer Komponenten
• Erhöhung des Anteils der AJAX-Unterstützung

Bei der Standardinstallation werden diese Mittel nicht bzw. wenig eingesetzt, wodurch die Webapplikation einfach bleibt. Die Umsetzung dieser Maßnahmen muss bei Bedarf erfolgen, da sie stark mit dem Website Template (CSS, Masterpage) des Lieferanten gekoppelt sind.

Insbesondere bei Angeboten mit begrenzter Verfügbarkeit, hilft die Verwendung eines Servicepools. Die Vergabe von Ressourcen erfolgt bereits bei Übernahme in den Warenkorb. Wenn ein Produkt ein Servicepool verwendet, ist die Entnahme einer Ressource aus dem Pool eine der ersten Aktionen im gesamten Bestellprozess. Bei zu hoher Nachfrage wird der Bestellprozess frühzeitig unterbunden und damit unnötige Nutzerinteraktion sowie Serverlast gespart.

Der Kunde hat nach erfolgreicher Zuteilung einer Ressource Zeit, die Transaktion durch Eingabe der Kundendaten und Zahlungsinformationen abzuschließen. Diese Zeit ist ausreichend groß, jedoch begrenzt. Beendet der Kunde den Bestellprozess nicht, wird die Ressource wieder freigegeben. Dauert der Bestellprozess zu lange, erlischt die Zuteilung ebenfalls und der Bestellprozess wird abgebrochen.

• Trennung von Kundenregistrierung und Bestellvorgang
• Verwendung vorkonfigurierter Zahlungsinformationen
• Nachgelagerte Zahlungsintegration

Durch ein Last-Monitoring wird die Last des Webservers gemessen. Basierend auf dem aktuellen Lastzustand können Abfragen abgewiesen werden.

Lastmessung

In der Website werden folgende Parameter gemessen:

• die Anzahl der aktuellen Threads (aktuell bearbeitete Anfragen)
• sie Gesamtauslastung der Website als Verhältnis von Belegtzeit und Leerlaufzeit
• die Last einzelner Sitzungen

Lastabwehr auf Sessionbasis

Mit dieser Maßnahme werden nur neue Sessions abgewiesen, wenn der Lastzustand einen kritischen Wert erreicht hat. Bestehende Sessions bleiben unbeeinträchtigt. Durch diese Maßnahme wird die Performance bestehender Sessions gesichtert. Da Sessions durch den Nutzer beendet werden (Schließen des Browserfesnters) oder sich bei Inaktivität selbst beenden, kann der Server einen Überlastzustand überwinden, bzw. er kann einen maximalen Lastzustand halten.

Lastabwehr einzelner Sitzungen

Das Lastmonitoring überwacht einzelne Sitzungen bezüglich der durch sie verursachten Anfragelast. Hierbei wird der durchschnittliche Anfrageintervall als gleitender Mittelwert bestimmt. Der Anfrageintervall ist die Zeit zwischen den Endezeitpunkten aufeinanderfolgender HTTP-Anfragen einer Sitzung. 

Der gleitende Mittelwert erkennt eine dauerhafte Lasterhöhung durch die Sitzung (Nutzer klickt wiederholt auf Neu laden), wodurch der gleitende Anfrageintervall einen Schwellwert unterschreitet (z.B. 2 sec.). Eine kurzzeitige Erhöhungung der Anfragefrequenz (z.B. bis 10 Anfragen ohne Pause) wird jedoch zugelassen, wenn der gleitende Anfrageintervall einen hohen Wert hat.

Bei Unterschreiten des einstellbaren Schwellwertes reagiert die Website:

• durch die Blockierung des Threads: der Webserver läßt den Thread ohne Abarbeitung bewusst eine bestimmte Zeit warten und verhindert dadurch weitere Anfragen.
• durch eine Umleitung auf einen anderen Server zur Anzeige einer Hinweismeldung
• durch eine Beendigung der Sitzung

Im Normalfall findet Validierung und Autorisierung in der Website und im Applikationsserver statt. Wenn Sie Server und Website als eine geschlossene Applikation planen und testen (befinden sich in der selben Sicherheitsumgebung), können Validierungs- und Autorisierungsaufgaben auf einem System wegfallen.

Die serverseitige Autorisierung ist insbesondere für den Einsatz als Webservice gedacht, wobei Sie den Server in einem Intranet oder im Internet freigeben, damit andere Applikationen mit SMACC zusammenarbeiten können. Hier

Kritische Lastzustände können i.d.R. nur bei der Kundenregistrierung und der Bestellungsaufnahme eintreten, wenn die oben genannten Lastfaktoren vorliegen. Normalerweise können die dabei stattfindenen komplexe Transaktionen vollständig ausgeführt werden stattfinden. 

Systemseitige Initialisierung

Die systemseitige Initialisierung dient der Systementlastung beim Bestellvorgang, indem Verarbeitungsschritte aus der Transaktion des Bestellvorgang in einen Hintergrundprozess verlagert werden. Diese Entlastung kann bezüglich folgender Verarbeitungsschritte konfiguriert werden:

• Erzeugung der Bestelldokumente
• Erzeugung der Schedule-Objekte
• Initialisierung der Schedule-Objekte (Erzeugung der initialen Raten)

Schreib-Cache (Draft)

Für extreme Situationen wird SMACC einen Schreib-Cache erhalten. Der Schreib-Cache erlaubt die Aufnahme von Kunden und Bestellungen ohne oder nur mit minimalen Datenbankzugriffen.

Die Verarbeitung beschränkt sich auf die Validierung und die Reservierung.