Architekturentscheidungen

Veröffentlicht: 01. Feb 2001 | Aktualisiert: 17. Jun 2004

Von Gregory Leake

Auf dieser Seite

 Prozessisolationsstufen und Leistung
 Ausskalieren mit Windows 2000-Network Load Balancing (NLB)
 Komponentenlastenausgleich
 Intelligente Partitionierung
 Auswirkung der Einführung von COM+-Transaktionen
  Dynamische SQL kontra gespeicherte Prozeduren
 Aufwärtsskalierung kontra Ausskalierung
  Schlussfolgerungen und Überlegungen zur Leistungsoptimierung

Prozessisolationsstufen und Leistung

Eine weitere Frage, die sich beim Bereitstellen einer Webanwendung stellt, ist die Frage der Prozessisolation. Wir haben die Visual Basic/ASP/COM+-Anwendung in verschiedenen Prozessisolationsstufen getestet, um zu veranschaulichen, welchen enormen Einfluss diese Entscheidung auf die Leistung hat. Aus den Ergebnissen lässt sich ableiten, dass die standardmäßigen, einsatzbereiten Prozessisolationsstufen für Webanwendungen, die auf ASP und COM+ basieren, nicht optimal sind und nach Möglichkeit angepasst werden sollten.

Der Begriff Prozessisolation bezieht sich auf das Partitionieren des ausgeführten Codes in verschiedene Prozessbereiche, die vom Betriebssystem verwaltet werden. Der grundlegende Gedanke hierbei ist, dass unter Windows 2000 (und Windows NT 4.0) der Ausfall eines Prozesses keinen Einfluss auf die anderen Prozesse hat. Wenn z.B. eine ASP-Anwendung durch eine Prozessisolation vom IIS-Webserver (InetInfo.exe) getrennt ist, kann die Anwendung ggf. abstürzen, aber der Webserver auf dem Computer kann weiterhin Seiten für andere Sites bereitstellen, so dass ein Absturz des gesamten Systems verhindert wird. Der Nachteil der Prozessisolation ist allerdings die Reduzierung der Leistung. Es ist kostenaufwendig, die Prozessgrenzen in einer Anwendung zu überwinden. Mit dem Datenmarshalling ist ein großer Overhead verbunden, der ein hohes Maß an CPU-Kontextänderungen erfordert. Unter Windows NT 4.0 ist der Kostenaufwand so hoch, dass alle neu erstellten ASP-Webanwendungen standardmäßig im Prozessbereich wie IIS ausgeführt werden. Unter Windows 2000 ist die Leistung der ASP-Anwendungen um einiges höher. In Windows 2000 wurde die Standardeinstellung geändert, so dass eine neu erstellte Anwendung in einem anderen Prozessbereich als der Webserver ausgeführt wird. Wenn Sie eigene Tests durchführen möchten, um die Leistung von Windows NT 4.0 gegenüber Windows 2000 zu vergleichen, sollten Sie dies berücksichtigen. Ein Vergleich von Windows 2000 mit einer Out-of-Process-Anwendung (Standardeinstellung) gegenüber Windows NT 4.0 mit einer In-Process-Anwendung (Standardeinstellung) liefert keine gültigen Ergebnisse, weil Sie in diesem Fall Äpfel mit Birnen vergleichen würden.

Als Nächstes befassen wir uns mit der Visual Basic/COM+/ASP-Anwendung und den drei grundlegenden Optionen, die zur Prozessisolation verfügbar sind. Dann erörtern wir den empfohlenen Ansatz basierend auf den Leistungsdaten. Die erste Option unter Windows 2000 ist das Zurücksetzen der Einstellung für die ASP-Anwendung auf die Standardeinstellung von Windows NT 4.0, so dass alle Operationen im Prozessbereich wie der Webserver ausgeführt werden. Dies ist die schnellste und einfachste Lösung. Bei Verwendung dieser Option muss zudem die Standardeinstellung einer beliebigen COM+-Anwendung von der Serveraktivierung (separater Prozessbereich für alle COM+-Objektinstanzen) in die Bibliotheksaktivierung (COM+-Objekte werden im Prozessbereich der aufrufenden Anwendung erstellt) geändert werden. Wenn Ihre ASP-Anwendung und COM+-Komponenten sehr ausgiebig getestet wurden und diese Anwendung zudem die einzige Anwendung ist, die über diesen Computer verwaltet wird, ist dies die beste Option, um die höchstmögliche Anzahl von gleichzeitigen Benutzerzugriffen bei konsistenter Leistung zu unterstützen.

Abbildung 11. Prozessisolation mit der Option zur Ausführung in einem einzelnen Prozess

Die nächste Option besteht darin, die Standardoption der ASP-Anwendung zur Prozessisolation beizubehalten, aber die Standardoption der COM+-Anwendungen von der Serveraktivierung in die Bibliotheksaktivierung zu ändern. Das heißt, dass alle COM+-Objekte im Prozessbereich erstellt werden wie die aufrufenden ASP-Seiten, wobei aber die ASP-Seiten (und daher COM+-Objekte) durch Prozessisolation vom Webserver getrennt werden. Dies ist eine sichere Konfiguration, aus der sich jedoch auch ein großer Leistungsoverhead ergibt, da IIS Daten zwischen ASP und dem IIS-HTTP-Server marshallen muss.

Diese Option eignet sich hervorragend für neue, relativ ungetestete Anwendungen oder für Server, auf denen mehrere Sites oder Anwendungen ausgeführt werden. Mit der Option wird sichergestellt, dass der Webserver andere Anwendungen weiterhin ausführen kann, wenn eine der Anwendungen abstürzt. Ein Fehler in einer COM+-Komponente führt nicht zum Ausfall des Webservers.

Abbildung 12. Prozessisolation mit isoliertem ASP/ISAPI-Prozess

Bei der letzten Option handelt es sich um die Standardeinstellung für neu erstellte ASP-Anwendungen, die COM+-Komponenten aufrufen. Hier wird die ASP-Anwendung als Out-of-Process-Anwendung und die COM+-Anwendung (Container für die COM+-Komponenten) als Serverpaket gekennzeichnet. Bei dieser Option ist jedoch erkennbar, dass sich der Prozess explosionsartig entwickelt. Für jeden ASP-Aufruf wird eine Prozessgrenze überschritten, wobei eine weitere Prozessgrenze für jede aktivierte COM+-Komponente überschritten wird. Dies führt zu einem großem Overhead und bedeutet für die Sites in vielen Fällen den "Overkill".

Abbildung 13. Prozessisolation mit isoliertem ASP/ISAPI- und COM+-Prozess

In der folgenden Abbildung werden für diese drei Optionen die Leistungsdaten der Nile-Anwendung für jede Prozessisolationskonfiguration veranschaulicht. Diese Daten wurden auf einem einzelnen Compaq ProLiant 8500-Computer gemessen.

Abbildung 14. Visual Basic/COM+- und ASP-Prozessisolationsänderungen

Es zeigt sich, dass die Prozessisolationsentscheidungen einen großen Einfluss auf die Leistung haben.

Ausskalieren mit Windows 2000-Network Load Balancing (NLB)

Der Lastenausgleich war ein wichtiger Aspekt bei den von Doculabs durchgeführten Windows 2000-Vergleichstests. Der Lastenausgleich ermöglicht einer Site das Ausskalieren über einen Cluster von Servern, so dass die Kapazität auf einfache Weise erhöht werden kann, indem dem Back-End weitere replizierte Server hinzugefügt werden. Zudem bietet der Lastenausgleich Redundanz, da der Site Failoverfunktionen bereitgestellt werden, so dass sie weitherhin verfügbar bleibt, auch wenn ein oder mehrere Server auf dem Back-End fehlschlagen (oder zum Durchführen von Wartungsaufgaben heruntergefahren werden müssen). Bei den jüngsten von den Anwendungsserveranbietern ausgetragenen Wettstreiten wurde von den meisten Anbietern ein Feature mit dem Namen dynamischer Lastenausgleich angepriesen und daher auch in der Presse und von Analysten erörtert. Ironischerweise ist der dynamische Lastenausgleich ein Feature, das nur in wenigen großen Websites verwendet wird. Stattdessen wird in den meisten großen Sites für das Ausskalieren vorwiegend eine simplere Form des Lastenausgleichs auf Netzwerkebene verwendet. Bei dieser Form werden eingehende IP-Anforderungen einfach an replizierte Server geleitet, anstatt individuelle Komponenten in einer Anwendung zu integrieren und die Logik basierend auf der verfügbaren Verarbeitungskapazität dynamisch zu verteilen. Warum ist diese Technik so weit verbreitet? Der Grund hierfür ist, dass der Netzwerklastenausgleich (NLB) funktioniert. Der Netzwerklastenausgleich ist simpel, lässt sich einfach einrichten und erledigt seine Aufgaben. Die meisten Anwendungsserver verwenden andererseits einen systemeigenen Blackbox-Algorithmus, um die Last auf mehrere Anwendungsserver zu verteilen. Dies funktioniert bei einigen gut und bei anderen weniger gut. Es kann sehr aufwendig sein, solche Datenzentren einzurichten und zu warten, insbesondere wenn die Verteilungs- bzw. Routinglogik komplex ist und für das System einen Leistungsengpass darstellt.

Der Netzwerklastenausgleich (NLB) ist ein Lastenausgleich auf Komponentenebene zum Verteilen der Last auf einen Cluster von Back-End-Servern, der viel häufiger als der dynamische Lastenausgleich verwendet wird. Es gibt sowohl Hardwarelösungen zum Bereitstellen von NLB-Diensten, z.B. CISCO Local Director, als auch Softwarelösungen, z.B. der einfache Round Robin DNS (RRDNS). Gute Lösungen weisen keinen Single Point of Failure (SPOF) auf. Der einfache RRDNS ist einfach zu verwenden, aber keine optimale Lösung, da bei einem fehlgeschlagenen Server im Cluster die eingehenden Anforderungen weiterhin an den Server geleitet werden. Wenn Sie also ein Cluster mit drei Servern verwenden und einer der Server fehlschlägt, wird ein Drittel der Anforderungen von den Clients nicht bearbeitet. Windows 2000 Advanced Server verfügt über integrierte NLB-Dienste. Dies ist ein wichtiges Feature, das bei jedem Websiteentwurf (für Intranet und Internet) berücksichtigt werden sollte. Mit Hilfe der Windows 2000-NLB-Dienste (NLBS) können Sie die durch eingehende Netzwerkanforderungen entstehende Last auf einfache Weise auf ein Cluster von Back-End-Servern verteilen. Es gibt keinen SPOF. Sollte ein Server fehlschlagen, werden alle Anforderungen innerhalb von weniger als einer Sekunde an die verbleibenden verfügbaren Server geleitet. Bei dem Doculabs-Vergleichstest haben wir für die Server Windows 2000-NLB als primären Lastenausgleichmechanismus verwendet. Dies ermöglichte eine lineare Skalierung (und darüber hinaus ein Failover bei den Verfügbarkeitstests) der Visual Basic-Anwendung über vier Server (die maximale Anzahl von Servern, die für den Test verwendet wurde).

NLB ermöglichte die lineare Skalierung der Visual C++-Anwendung über zwei Server. Da die Visual C++-Anwendung jedoch mehr dynamische Seiten pro Sekunde bereitstellt, ist die Datenbankbelastung viel höher. Daraus ergab sich eine verringerte Durchsatzleistung, wenn den beiden Servern in der mittleren Ebene ein dritter oder vierter Server hinzugefügt wurde. Zu diesem Zeitpunkt wurde die SQL Server 7.0-Datenbank bei einer CPU-Auslastung von mehr als 85 Prozent ausgeführt. Der begrenzende Faktor war nicht mehr die mittlere Anwendungsebene, sondern die Datenbank. Der einzige Weg zur weiteren Skalierung der Visual C++-Anwendung bestand darin, eine Möglichkeit zur Verteilung der Last auf mehrere Datenbankserver zu finden. Sehen wir uns die Daten einmal an:

Folgende Angaben sollen die Daten in die richtige Perspektive rücken: 8.452 Seiten pro Sekunde entspricht 730.252.800 bereitgestellten Seiten pro Tag. Dies entspricht der doppelten Menge des täglichen Internetverkehrs von Yahoo (der Website mit den meisten Besuchern) an einem geschäftigen Tag. Dies ist keine schlechte Leistung für einen einzelnen SQL Server 7.0-Datenbankserver, wenn man bedenkt, dass im Vergleichstest bei 90 Prozent der Nile-Seiten eine Datenbankabfrage ohne Middle-tier-Zwischenspeicherung erfolgt. Natürlich ist die Nile-Anwendung eine sehr einfache Anwendung, aber sie lässt erahnen, warum SQL Server in Bezug auf die absolute Leistung vier der sechs besten TPC-C-Ergebnisse aller Zeiten erzielt, wobei SQL Server auch den ersten Platz dieser Rangfolge belegt.

Für die weitere Ausskalierung der Visual C++-Nile-Anwendung ist eine Art von Datenbankpartionierung über mehrere Server erforderlich. Eine andere Möglichkeit besteht darin, einen Ansatz zur Aufwärtsskalierung zu verwenden und die SQL-Datenbank auf einem leistungsstärkeren Computer auszuführen, z.B. auf dem neuen Compaq und Unisys E7000, der bis zu 32 CPUs unterstützt. Zudem ermöglicht das neue SQL Server 2000-Feature für verteilte partitionierte Ansichten (DPV = Distributed Partitioned Views) eine weitere Skalierung, indem bestimmte Datenbanktabellen zergliedert und über mehrere parallel arbeitende Back-End-Server verteilt werden.

Komponentenlastenausgleich

Während Windows 2000 Advanced Server einen Netzwerklastenausgleich (NLB) bereitstellt, wird in Application Center 2000 der Komponentenlastenausgleich (CLB = Component Load Balancing) eingeführt, ein dynamischer Lastenausgleich von individuellen COM+-Remotekomponenten innerhalb der Anwendung. Dies ist ein nützliches Feature, da es beim Einsatz von Remotekomponenten eine Programmiertransparenz ermöglicht. Einer der Gründe für die Verwendung von COM+ zum Erstellen einer logischen n-tier-Anwendung ist die Flexibilität bei der Bereitstellung. Die Anwendung kann entweder in einer physikalischen Two-tier- oder einer physikalischen n-tier-Datenzentrumarchitektur bereitgestellt werden. Anders ausgedrückt: Sie können die COM+-Komponenten auf dem lokalen aufrufenden Webserver ausführen oder einige bzw. alle Komponenten vom Webserver entfernen und auf eine dedizierte Ebene von Anwendungsservern verteilen.

Grundsätzlich gilt jedoch, dass ebenso wie bei der Out-of-Process-Ausführung von Komponenten, bei der die Komponente nicht im Prozessbereich des Webservers ausgeführt wird, auch bei der Ausgliederung der Komponenten vom Webserver und der Remoteausführung dieser Komponenten die Leistung verringert wird. Dies ist auf das Marshalling der COM+-Daten über das Netzwerk und auf die zusätzlichen Netzwerkzugriffe zurückzuführen, die zur Komponenteninteraktion erforderlich sind. Nichtsdestotrotz möchten viele Kunden die Logik von den Webservern ausgliedern und eine Remotelogik verwenden. Hierfür gibt es verschiedene Gründe. So besteht z.B. die Möglichkeit, einen zusätzlichen Firewall zwischen dem Webserver und den Komponenten zu errichten, die mit geschützten Subsystemen zusammenarbeiten, z.B. internen Systemen zur Planung der Unternehmensressourcen (z.B. SAP R/3), Kundendatenbanken usw.

Doculabs hat in unserem Auftrag die Nile-Anwendung unter Verwendung einer physikalischen Three-tier-Datenzentrumarchitektur getestet, um festzustellen, welchen Einfluss das Verwenden von COM+-Remotekomponenten auf die Leistung hat. Abbildung 15 zeigt anhand einer Visual C++/ISAPI/COM+-Anwendung den deutlichen Leistungsunterschied zwischen der In-Process-Ausführung aller COM+-Komponenten und der Remoteausführung von Komponenten, die sich auf einem einzelnen Anwendungsserver befinden. Für dieses Szenario kann die Durchsatzkurve nur verbessert werden, indem zusätzliche Anwendungsserver hinzugefügt werden (in diesem Fall stellt der einzelne Anwendungsserver den Leistungsengpass dar). Grundsätzlich gilt jedoch, dass viel mehr Hardware erforderlich ist, um die gleiche Leistung wie bei lokalen In-Process-Komponenten zu erzielen.

Abbildung 15. Visual C++ COM+-Objekte: Lokale Ausführung und Remoteausführung im Vergleich

Intelligente Partitionierung

Ist es ratsam, alle Komponenten des Webservers als Remotekomponenten zu verwenden? Die Antwort zu dieser Frage lautet nein. Wenn in Ihrem Datenzentrum und in der Anwendung selbst die Sicherheitseinstellungen ordnungsgemäß implementiert wurden, ergibt sich durch die Remoteausführung einzelner COM+-Komponenten tatsächlich kein sicherheitstechnischer Vorteil. Als Nächstes befassen wir uns im Hinblick auf die intelligente Partitionierung der Anwendungslogik mit den einzelnen Komponenten der Nile-Anwendung. Tatsächlich handelt es sich bei den meisten Komponenten, auf die die Nile-Anwendung zugreift, um Komponenten, die auf dem Server Benutzeroberflächenoperationen durchführen, z.B. dynamisches Generieren von HTML-Seiten basierend auf den Ergebnissen der Katalogsuche, Ad-hoc-Produktsuchen usw. Hierbei handelt es sich um Leseoperationen in einem i.d.R. schreibgeschützten Produktkatalog, der für diese Komponenten offen gelegt wird (der aktualisierbare Hauptkatalog kann z.B. ein internes System sein, das nicht im Internet offen gelegt wird).

Andere Komponenten der Nile-Anwendung haben Zugriff auf vertraulichere Datenbankinformationen, z.B. die Komponente, die die Interaktionen (Lese- und Schreiboperationen) mit der Kundendatenbank behandelt, oder die Komponente, die eine Bestelltransaktion in den Checkout platziert. Wenn die Wahrung der Sicherheit der Hauptgrund dafür ist, warum Sie die Logik vom Webserver ausgliedern und eine Remotelogik verwenden, sollten Sie darüber nachdenken, Ihre Klassendateien zu partitionieren, damit Sie für die Komponenten, bei denen dies tatsächlich sinnvoll ist, eine Remoteausführung wählen können (ohne dass Sie alle Komponenten per Remotezugriff aufrufen müssen, einschließlich der einfachen Komponenten, die einfach nur dazu dienen, die HTML-Benutzeroberfläche zu generieren). Es gibt bei der Nile-Anwendung und auch bei den meisten anderen Anwendungen drei Aspekte, bei denen diese intelligente Partitionierung und die selektive Auswahl der Remoteausführung einzelner Komponenten sehr wichtig sind:

1. Die meisten Komponenten, die zum Generieren der Benutzeroberfläche verwendet werden, geben eine große Datenmenge zurück an den Client. Sie rufen Produktinformationen aus der Datenbank ab, generieren die nachfolgende HTML-Ausgabe und geben diese Daten zurück an den Webserver, der diese dann an den Client sendet. Wenn diese Komponenten als Remotekomponenten verwendet werden, entsteht dadurch ein erheblicher Overhead beim Datenmarshalling, und die Leistung wird sehr beeinträchtigt.

2. Komponenten, die Kundendatensätze aktualisieren oder Bestelltransaktionen verarbeiten, geben im Gegensatz dazu oft nur wenige Daten an den Client zurück (z.B. eine Auftragsbestätigungsnummer), jedoch keine große Datenmenge zur Anzeige. Wenn diese Komponenten als Remotekomponenten verwendet werden, ergeben sich daraus i.d.R. keine großen Leistungseinbußen.

3. Wenn Sie sich das Verkehrsmuster für eine typische Website ansehen, werden Sie feststellen, dass der meiste Internetverkehr auf den Seiten stattfindet, auf denen Produktsuchen, allgemeine Suchen usw. durchgeführt werden können, und nicht auf den Seiten, auf denen Produkte bestellt oder vertrauliche Kundeninformationen aktualisiert werden können.

Kombiniert man diese drei wichtigen Aspekte, lässt sich Folgendes ableiten: Es ist sinnvoll, die Komponenten, die auf vertrauliche Bereiche unseres Systems zugreifen, als Remotekomponenten zu verwenden. Hierbei entsteht nicht annähernd soviel Overhead wie bei der Remoteausführung von Komponenten, die zahlreiche Benutzeroberflächenoperationen durchführen. Ein weiterer Grund für die Remoteausführung dieser Komponenten ist ihre lange Ausführungszeit und die erforderliche Interaktion mit mehreren Systemen. Durch einen Remotezugriff kann die Verarbeitungslast der Webserver reduziert werden.

Bei der Nile-Anwendung haben wir den Code auf diese Weise intelligent partitioniert und dann bestimmte Kriterien angewendet, um zu entscheiden, ob einzelne Komponenten auf den Webservern oder auf einem dedizierten Cluster von Anwendungsservern unter Verwendung von CLB ausgeführt werden. Als Erstes wurde geprüft, ob die Komponente Datenbanktransaktionen durchführt bzw. ob ein Schreibzugriff auf die Datenbank erfolgt. Wenn dies der Fall war, haben wir uns für die Remoteausführung der Komponente entschieden. Als zweites Kriterium wurde geprüft, ob die Datenbank auf die Kundendatenbank zugreift (Lese- oder Schreibzugriffe). Wenn dies zutraf, haben wir für die Komponente die Remoteausführung gewählt. Wenn die Komponente nur auf die schreibgeschützte Produktdatenbank zugreift, um Suchanforderungen zu verarbeiten, haben wir die Komponente weiterhin lokal als eine Erweiterung zum Webserver ausgeführt. Für den Vergleichstest hat Doculabs eine Kombination von sechs verschiedenen Benutzerprofilen verwendet, die nach Meinung von Doculabs die typischen Verwendungsmuster einer E-Commerce-Site darstellen: Die Profile werden zum Durchführen unterschiedlicher Operationen verwendet, z.B. zum Durchführen von Produktsuchen bzw. allgemeinen Suchen, Bestellen von Artikeln, Erstellen oder Aktualisieren von Kundenkonten usw. Abbildung 16 zeigt die Leistungskurve einer Anwendung, bei der eine intelligente Auswahl bei der Remoteausführung von Komponenten getroffen wurde, im Vergleich zur Leistungskurve einer Anwendung, bei der alle Komponenten lokal ausgeführt werden.

Abbildung 16. Intelligente Remoteausführung von COM+-Objekten im Vergleich zur ausschließlichen lokalen Ausführung

Anhand der Abbildung können Sie erkennen, dass die Leistung deutlich beeinflusst wird, wenn im Gegensatz zur reinen Remoteausführung aller Systemkomponenten eine intelligente Auswahl bei der Remoteausführung von Komponenten getroffen wird. Daher müssen Sie genau über die Gründe nachdenken, die für eine Remoteausführung von Komponenten sprechen, und dann eine weise Entscheidung darüber treffen, welche Komponenten lokal ausgeführt werden und bei welchen Komponenten eine Remoteausführung erfolgt.

Schließlich haben wir eine Konfiguration mit mehreren Webservern und mehreren dedizierten Anwendungsservern getestet, die in einer intelligenten Remotekonfiguration ausgeführt wurden (basierend auf den oben genannten Kriterien). Hierfür haben wir erstmals eine Gruppe von Compaq ProLiant 1850r-Servern verwendet, die im Hintergrund der Front-End-Webserver der Visual Basic/COM+/ASP-Implementierung als dedizierte Anwendungsserver ausgeführt wurden. Alle Compaq Proliant 8500-Computer sind über NLB geclustert und fungieren als redundante COM+-Router für die Anwendungsserver, wobei kein SPOF vorhanden ist. Die 1850r-Server werden mit Hilfe von CLB zu einem Cluster verbunden, der einfach nur dazu dient, die COM+-Komponenten auszuführen, die nicht mehr lokal auf dem Webserver ausgeführt werden und auf einen anderen Server verteilt wurden. Auch auf dieser Schicht befindet sich kein SPOF, da CLB, wie auch NLB, Failoverfunktionen bereitstellt, falls in der Anwendungsschicht ein Server bzw. mehrere Server fehlschlagen. Folgende Ergebnisse wurden erzielt:

Abbildung 17. Intelligente Verteilung im Vergleich zu ausschließlich lokalen Objekten

Beachten Sie, dass die Durchsatzkurve der verteilten Konfiguration, bei der ein Komponentenlastenausgleich verwendet wird, früher abzufallen beginnt als die Durchsatzkurve der Konfiguration, bei der nur lokale Objekte verwendet werden. Der Grund hierfür ist, dass die Anwendungsebene (die 1850r-Server) nach einem bestimmten Punkt gesättigt ist. Durch das Hinzufügen weiterer dedizierter Anwendungsserver würde die blaue Linie geradliniger verlaufen und mit der Durchsatzkurve der Konfiguration übereinstimmen, bei der ausschließlich lokale Objekte verwendet werden. Hierfür ist jedoch zusätzliche Hardware in der Anwendungsebene erforderlich.

Auswirkung der Einführung von COM+-Transaktionen

Einer der wichtigsten Dienste, die von COM+ bereitgestellt werden, ist die Unterstützung von verteilten Transaktionen zwischen Komponenten. In Bezug auf die Nile-Anwendungsdaten wurde uns oft die Frage gestellt, ob die Transaktionen für den Vergleichstest deaktiviert wurden. Bei der ursprünglichen PC Week-Testkonfiguration wurden die Transaktionen deaktiviert, da die Verarbeitung von Transaktionen nicht zu den Leistungskriterien des Vergleichstests gehörte und in keiner Anwendung eines Drittanbieters ein Transaktionsverarbeitungsmonitor integriert war.

Als Nächstes werden wir erörtern, was passiert, wenn wir die Transaktionsunterstützung für die COM+-Komponenten in der Nile-Anwendung deaktivieren und diese Komponenten als transaktionserfordernde Komponenten kennzeichnen. Dadurch wird der Microsoft Distributed Transaction Coordinator (DTC) für jeden Komponentenaufruf initiiert. Dies führt jedoch, wie Sie sich sicher vorstellen können, zu einem Overhead im System. Gehen wir zurück zur Diskussion über die Remoteausführung von Komponenten basierend auf der intelligenten Partitionierung. Wir könnten einfach die gleiche Logik auf die Frage der Transaktionsunterstützung anwenden. Finden in allen Komponenten der Nile-Anwendung Datenbanktransaktionen statt? Die Antwort lautet nein. Tatsächlich ist für keine der Komponenten eine COM+-Transaktionsunterstützung erforderlich, da in der Anwendung nur einfache Transaktionen unter Verwendung einer einzelnen Datenbank durchgeführt werden, die auf einfache Weise direkt in gespeicherten Prozeduren behandelt werden können. Wir sind jedoch einen Schritt weitergegangen und haben die Logik der Nile-Anwendung intelligent partitioniert. Auf diese Weise konnten wir die Transaktionsunterstützung für alle Komponenten aktivieren, die in der Auftrags- oder Kundendatenbank Schreiboperationen durchführen, und die Transaktionsunterstützung für Komponenten, die nur einfache select-Anweisungen durchführen, deaktiviert lassen. Abbildung 18 zeigt, welche Auswirkung die intelligente Verwendung von Transaktionen im Vergleich zur willkürlichen Aktivierung von COM+-Transaktionen für jede COM+-Komponente im System hat. Die in Abbildung 18 gezeigten Ergebnisse wurden mit einer Visual C++-Anwendung erzielt, die auf einem einzelnen Compaq ProLiant 8500-Webserver/Anwendungsserver ausgeführt wurde.

Abbildung 18. Intelligentes Verwenden von COM+-Transaktionen

Auch diese Ergebnisse zeigen erneut, dass sorgfältig überlegt werden sollte, welche Komponenten eine Transaktionsunterstützung erfordern. Basierend auf diesen Überlegungen können Sie die Klassendateien dann intelligent partitionieren, damit Sie einzelne Komponenten als transaktionserfordernd kennzeichnen können.

Dynamische SQL kontra gespeicherte Prozeduren

Wir bevorzugen die Verwendung von gespeicherten Prozeduren i.d.R. dann, wenn die SQL-Anweisung schon vorher bekannt ist (und nicht durch die Verwendungs-/Anwendungslogik dynamisch generiert wird). Die Verwendung von gespeicherten Prozeduren verbessert die Verwaltbarkeit des Systems. Dies trifft nicht zu, wenn die SQL-Zeichenfolgen direkt in eine Anwendung eingebettet werden. Zudem verfügt SQL Server über einen vorkompilierten Abfrageplan und kann mit Hilfe dieses Plans schneller arbeiten, als dies bei der Verwendung von dynamischer SQL der Fall ist. Das Diagramm in Abbildung 19 zeigt die Leistungskurven bei ausschließlichem Einsatz von dynamischer SQL in der Nile-ASP-Anwendung im Vergleich zur Verwendung von gespeicherten Prozeduren.

Abbildung 19. Ausschließlicher Einsatz von dynamischer SQL in der Nile-ASP-Anwendung im Vergleich zur Verwendung von gespeicherten Prozeduren

Aufwärtsskalierung kontra Ausskalierung

Abschließend haben wir getestet, welchen Einfluss eine Aufwärtsskalierung auf die Anwendung hat, indem wir die Anwendung auf Windows 2000-Systemen mit acht CPUs und zum Vergleich auf Windows 2000-Systemen mit vier CPUs ausgeführt haben. Die Daten in Abbildung 20 veranschaulichen, dass durch das Hinzufügen von Prozessoren zum System keine lineare Skalierung erzielt wird. Das Ausskalieren (Hinzufügen von replizierten Computern) ist i.d.R. effizienter, als den Servern weitere Prozessoren hinzuzufügen. Jedoch haben sowohl die Aufwärtsskalierung als auch die Ausskalierung eine wichtige Bedeutung. Durch Aufwärtsskalierung kann die Anzahl der Server, die zum Behandeln der Benutzerlast erforderlich ist, erheblich reduziert werden. Dadurch fallen weniger Kosten für das Verwalten des Datenzentrums an. Die Ausskalierung ermöglicht Ihnen jedoch eine inkrementelle Skalierung bei geringem Kostenaufwand und bietet eine hervorragende Failoverunterstützung für umfassend verfügbare Websites. Mit der neuen Anwendung Windows 2000 Datacenter Server können Sie zudem Anwendungen auf Systemen mit bis zu 32 CPUs ausführen und individuelle CPUs für bestimmte Anwendungen zuweisen, wodurch die Möglichkeiten zur Serverkonsolidierung erweitert werden. Darüber hinaus kann Windows 2000 Datacenter Server die Prozessoren automatisch neu konfigurieren, um bestimmten Anwendungen zusätzliche CPUs zuzuweisen, falls bei diesen Anwendungen eine CPU-Sättigung eingetreten ist.

Abbildung 20. Skalieren von vier auf acht Prozessoren mit Windows 2000

Schlussfolgerungen und Überlegungen zur Leistungsoptimierung

In der folgenden Liste werden die wichtigsten Schritte zum Erstellen und Optimieren der Nile-Implementierungen aufgeführt:

• Testen und optimieren Sie die Anwendung unter Belastungsbedingungen.

  • Legen Sie Leistungsziele fest.

  • Suchen und beseitigen Sie Leistungsengpässe, bis die gesteckten Leistungsziele erreicht werden.

• Optimieren Sie die Datenbank, ein wichtiger Schritt zur Leistungssteigerung.

  • Zweckmäßige Indizes sind von entscheidender Bedeutung.

  • Beobachten Sie die CPU-Auslastung von SQL Server. Sie sollte unter normalen Belastungen gering und bei geringfügiger Belastung sehr niedrig sein.

• Konfigurieren Sie die Datenbank ordnungsgemäß (verwenden Sie z.B. parallele RAID-Controller und separate Geräte zur Transaktionsprotokollierung).

• Verwenden Sie statusfreie Datenbankoperationen und nur getrennte Recordsets.

• Verwenden Sie geeignete ADO-Codierungstechniken (weitere Informationen finden Sie unter FMStocks 2000 [in Englisch] und in den Beispielen zur Anwendung Nile [in Englisch] in MSDN Online):

  <font size=1>rs.CursorLocation = adUseClient 
  rs.Open cmd, , adOpenForwardOnly, adLockReadOnly  
  

• Vermeiden Sie Folgendes:

  • Einzeilige Recordsets (verwenden Sie Ausgabeparameter) und adExecutenoRecords.

  • Große Recordsets (Hunderte sind OK, aber Tausende nicht).

• Führen Sie ASP oder ISAPI prozessintern (In-Process) oder prozessisoliert aus, aber führen Sie das COM+-Paket nach Möglichkeit prozessintern (Bibliothekspaket) aus.

• Verwenden Sie Windows 2000-NLB.

• Verteilen Sie nicht willkürlich alle COM+-Komponenten mit Hilfe von CLB, sondern wenden Sie intelligente Kriterien an. Viele Objekte, auch die benutzeroberflächenintensiven Objekte, die auf schreibgeschützte Daten zugreifen, müssen nicht verteilt werden.

• Verwenden Sie COM+-Transaktionen auf sinnvolle Weise.

• Deaktivieren Sie nichtverwendete COM+-Features, z.B. Ereignisse und Status, Synchronisierung, Transaktionen und JIT.

• Vergeuden Sie Ihre Zeit nicht mit Middle-tier-Caches, da sie ggf. nicht erforderlich sind.

• Verwenden Sie für den Benutzerstatus eine Datenbank oder einen Client, wann immer dies möglich ist, und vermeiden Sie die Verwendung von IIS-Sitzungsobjekten und Anwendungsobjekten.

• Verwenden Sie für Operationen mit langer Ausführungsdauer (z.B. Bestellungen und Interaktionen mit Legacysystemen), asynchrone Operationen (COM+LCE, Message Queuing).