Archiv für das Jahr: 2015

Während sich das Zwischenspeichern von Daten im Application- oder Session-Objekt empfiehlt, kann das Zwischenspeichern von COM-Objekten große Nachteile haben. Es liegt oft nahe, häufig verwendete COM-Objekte in das Application- oder Session-Objekt abzulegen. Leider führen viele COM-Objekte, darunter alle in Visual Basic 6.0 oder früher verfassten, beim Speichern des Application- oder Session-Objekts zu schwerwiegenden Engpässen.

Insbesondere nicht bewegliche Komponenten führen beim Zwischenspeichern im Application- oder Session-Objekt zu Leistungsengpässen. Eine bewegliche Komponente ist eine mit ThreadingModel=Both markierte Komponente, die den FTM (Free-threaded Marshaler) aggregiert, oder eine mit ThreadingModel=Neutral markierte Komponente. (Das neutrale Modell wird erstmals in Windows 2000 und COM+ verwendet.) Folgende Komponenten sind nicht beweglich:

1. Freethread-Komponenten (es sei denn, sie aggregieren den FTM)
2. Apartmentthread-Komponenten
3. Singlethread-Komponenten

Konfigurierte Komponenten (Microsoft Transaction Server (MTS)/COM+-Bibliothek und Serverpakete/-anwendungen) sind nicht beweglich, es sei denn, sie sind neutralthreaded. Apartmentthread-Komponenten und andere nicht bewegliche Komponenten funktionieren am besten im Gültigkeitsbereich der Seite (d. h. sie werden auf einer einzelnen ASP-Seite erstellt und gelöscht).

In IIS 4.0 wurde eine mit ThreadingModel=Both markierte Komponente als beweglich angesehen. In IIS 5.0 reicht das nicht länger aus. Die Komponente muss nicht nur mit Both markiert sein, sondern muss auch den FTM aggregieren. Der Artikel zur Beweglichkeit beschreibt, wie mit der Active Template Library geschriebene C++-Komponenten dazu veranlasst werden, den FTM zu aggregieren. Wenn Ihre Komponente Schnittstellenzeiger zwischenspeichert, müssen auch diese Zeiger selbst beweglich sein oder in der COM-GIT (Global Interface Table) gespeichert sein. Wenn sich eine Boththread-Komponente nicht zum Aggregieren des FTM neu kompilieren lässt, können Sie sie als ThreadingModel=Neutral markieren. Wenn IIS keine Beweglichkeitsprüfung durchführen soll (d. h. wenn nicht bewegliche Komponenten nicht im Gültigkeitsbereich des Application- oder Session-Objekts gespeichert werden sollen), können Sie AspTrackThreadingModel stattdessen in der Metabasis auf True festlegen. Es wird davon abgeraten, AspTrackThreadingModel zu ändern.

IIS 5.0 gibt einen Fehler aus, wenn Sie versuchen, eine nicht bewegliche, mit Server.CreateObject erstellte Komponente im Application-Objekt zu speichern. Sie können dies durch Verwenden von <object runat=server scope=application …> in der Datei Global.asa umgehen. Davon wird aber abgeraten, da dies wie unten erläutert zu Marshalling und Serialisierung führt.

Was läuft beim Zwischenspeichern nicht beweglicher Komponenten schief? Eine nicht bewegliche, im Session-Objekt zwischengespeicherte Komponente „bindet“ das Session-Objekt an einen ASP-Arbeitsthread. ASP verwaltet einen Pool von Arbeitsthreads, die von Diensten angefordert werden. Normalerweise wird eine neue Anforderung vom ersten verfügbaren Arbeitsthread verarbeitet. Wenn eine Sitzung an einen Thread gebunden ist, muss die Anforderung warten, bis der verknüpfte Thread verfügbar wird. Hierzu eine Analogie, die dies möglicherweise verständlicher macht: Sie gehen zum Supermarkt, kaufen Lebensmittel und bezahlen für diese an Kasse 3. Danach müssen Sie beim Einkaufen in diesem Supermarkt jedes Mal an Kasse 3 bezahlen, selbst wenn die Schlangen an anderen Kassen kürzer sind, oder es Kassen ohne Warteschlangen gibt.

Das Speichern nicht beweglicher Komponenten im Gültigkeitsbereich des Application-Objekts wirkt sich noch negativer auf die Leistung aus. ASP muss einen Spezialthread erstellen, um nicht bewegliche Komponenten im Gültigkeitsbereich des Application-Objekts auszuführen. Dies hat zwei Konsequenzen: Alle Aufrufe müssen zu diesem Thread gemarshallt und alle Aufrufe müssen serialisiert werden. Marshalling bedeutet, dass die Parameter in einem freigegebenen Bereich des Arbeitsspeichers gespeichert werden müssen. Am Spezialthread muss eine kostspielige Kontextänderung durchgeführt und die Methode der Komponente ausgeführt werden. Die Ergebnisse werden in einen freigegebenen Bereich gemarshallt, und eine weitere kostspielige Kontextänderung gibt die Kontrolle an den Originalthread zurück. Serialisierung bedeutet, dass alle Methoden nacheinander ausgeführt werden. Es ist nicht möglich, dass zwei unterschiedliche ASP-Arbeitsthreads gleichzeitig Methoden an einer freigegebenen Komponente ausführen. Dadurch wird Parallelität, insbesondere auf Mehrprozessorcomputern, verhindert. Am schlimmsten ist aber, dass allen nicht beweglichen Komponenten im Gültigkeitsbereich des Application-Objekts ein Thread (der „Host-STA“) gemeinsam ist. Dadurch werden die Auswirkungen der Serialisierung noch verstärkt.

Schwirrt Ihnen der Kopf? Dann dürften diese allgemeinen Regeln helfen. Wenn Sie Objekte in Visual Basic (6.0) oder früher schreiben, zwischenspeichern Sie sie nicht im Application- oder Session-Objekt. Wenn Ihnen das Threading-Modell eines Objekts nicht bekannt ist, sollten Sie es nicht zwischenspeichern. Anstatt nicht bewegliche Objekte zwischenzuspeichern, empfiehlt es sich, diese auf jeder Seite zu erstellen und freizugeben. Die Objekte werden direkt auf dem ASP-Arbeitsthread ausgeführt, so dass es nicht zu Marshalling oder Serialisierung kommt. Die Leistung ist angemessen, wenn die COM-Objekte im IIS-Feld ausgeführt werden, und wenn das Initialisieren und Löschen der COM-Objekte nicht besonders zeitaufwendig ist. Beachten Sie, dass Singlethread-Objekte nicht auf diese Weise verwendet werden sollten. Seien Sie vorsichtig: VB kann Singlethread-Objekte erstellen! Wenn Sie Singlethread-Objekte auf diese Weise (z. B. als Microsoft Excel-Tabelle) verwenden müssen, sollten Sie keinen hohen Durchsatz erwarten.

ADO-Recordsets können problemlos zwischengespeichert werden, wenn ADO als Freethread-Komponente markiert ist. Verwenden Sie die Datei Makfre15.bat, um ADO als Freethread-Komponente zu markieren. Diese befindet sich in der Regel im Verzeichnis \\Programme\Gemeinsame Dateien\System\ADO.

Warnung ADO sollte nicht als Freethread-Komponente markiert werden, wenn Microsoft Access als Datenbank verwendet wird. Das ADO-Recordset muss außerdem abgetrennt sein. Wenn Sie die ADO-Konfiguration auf Ihrer Site nicht steuern können (z. B. wenn Sie als unabhängiger Softwarehersteller eine Webanwendung an Kunden verkaufen, die ihre eigenen Konfigurationen verwalten), ist es im Allgemeinen wahrscheinlich besser, Recordsets nicht zwischenzuspeichern.

Wörterbuchkomponenten stellen ebenfalls bewegliche Objekte dar. Das LookupTable-Objekt lädt Daten aus einer Datendatei und ist sowohl für Kombinationsfelddaten als auch Konfigurationsinformationen geeignet. Das PageCache-Objekt von Duwamish Books stellt ebenso wie das Caprock-Lexikon Wörterbuchsemantiken bereit. Diese Objekte oder Ableitungen davon können die Grundlage einer effektiven Zwischenspeicherungsstrategie bilden. Beachten Sie, dass das Scripting.Dictionary-Objekt NICHT beweglich ist und nicht im Gültigkeitsbereich eines Application- oder Session-Objekts gespeichert werden sollte.

Nachdem Ihnen nun die Vorteile des Zwischenspeicherns im Application- und Session-Objekt bekannt sind, schlagen wir vor, das Session-Objekt zu meiden. Wie Sie im Folgenden sehen werden, haben Sitzungen, die auf viel verwendeten Sites verwendet werden, mehrere Nachteile. Bei viel verwendeten Sites handelt es sich um Sites mit Anforderungen von Hunderten von Seiten pro Sekunde oder Tausenden von gleichzeitigen Benutzern. Dieser Tipp ist noch wichtiger für Sites, die horizontal skalieren müssen, d. h. Sites, die mehrere Server zum Bewältigen der Belastung oder zum Implementieren von Fehlertoleranz verwenden. Bei kleineren Sites, wie z. B. Intranetsites, sind die praktischen Aspekte von Session-Objekten den Mehraufwand wert.

Zusammenfassend gilt, dass ASP für jeden Benutzer, der einen Webserver abfragt, ein Session-Objekt erstellt. Für jedes Session-Objekt ist (zusätzlich zu den in diesem gespeicherten Daten) ein Speicheraufwand von 10 KB erforderlich, und jedes Session-Objekt verlangsamt die Abfragen geringfügig. Das Session-Objekt bleibt aktiv, bis eine konfigurierbare Zeitüberschreitung (in der Regel 20 Minuten) erreicht wird.

Das größte Problem bei Session-Objekten ist nicht die Leistung, sondern die Skalierbarkeit. Session-Objekte sind nicht webserverübergreifend. Wenn ein Session-Objekt auf einem Server erstellt wurde, verbleiben seine Daten auf diesem. Wenn Sie Session-Objekte in einer Webservergruppe verwenden, müssen Sie also eine Strategie entwickeln, damit die Anfragen aller Benutzer an den Server geleitet werden, auf dem sich das Session-Objekt befindet. Dies wird als „feste Zuweisung“ eines Benutzers zu einem Webserver bezeichnet. Daraus wird der Begriff „fest zugewiesene Sitzungen“ abgeleitet. „Fest zugewiesene“ Benutzer verlieren Ihren Sitzungszustand, wenn der Webserver abstürzt, da die Session-Objekte nicht auf der Festplatte gespeichert sind.

Strategien zum Implementieren von fest zugewiesenen Sitzungen umfassen Hardware- und Softwarelösungen. Lösungen, wie z. B. das Programm für Netzwerklastenausgleich in Windows 2000 Advanced Server und Local Director von der Firma Cisco, können fest zugewiesene Sitzungen auf Kosten einer gewissen Skalierbarkeit implementieren. Diese Lösungen sind aber nicht perfekt. Das Einbringen eigener Softwarelösungen ist zurzeit auch nicht empfehlenswert (wir haben es mit ISAPI-Filtern und URL-Veränderungen u. ä. versucht)

Das Application-Objekt ist ebenfalls nicht serverübergreifend. Wenn Anwendungsdaten über die Webservergruppe freigegeben und aktualisiert werden müssen, müssen Sie eine Back-End-Datenbank verwenden. Schreibgeschätzte Anwendungsdaten sind jedoch in Webservergruppen weiterhin nützlich.  

Die meisten unternehmenskritischen Sites möchten mindesten zwei Webserver bereitstellen, selbst wenn der einzige Grund hierfür ein Erhöhen der Betriebszeit (der Umgang mit Ausfüllen und Serverwartung) ist. Aus diesem Grund müssen Sie beim Entwerfen einer unternehmenskritischen Anwendung entweder „fest zugewiesene Sitzungen“ implementieren oder Session-Objekte sowie sonstige Zustandsverwaltungsmethoden vermeiden, die den Benutzerzustand auf individuellen Webservern speichern.  

Wenn Sie keine Session-Objekte verwenden, denken Sie daran, sie zu deaktivieren. Sie können für Ihre Anwendung dazu den Internetdienste-Manager verwenden (siehe ISM-Dokumentation). Wenn Sie sich für die Verwendung von Session-Objekten entscheiden, können Sie ihre Auswirkungen auf die Leistung auf verschiedene Weise minimieren.

Sie können Inhalt, der keine Session-Objekte benötigt, (wie z. B. Hilfebildschirme, Besucherbereiche usw.) in eine separate ASP-Anwendung verschieben, für die Session-Objekte deaktiviert sind. Sie können ASP Seite für Seite darüber informieren, dass das Session-Objekt auf einer bestimmten Seite nicht benötigt wird. Positionieren Sie dazu folgende Anweisung am oberen Rand der ASP-Seite.

<% @EnableSessionState=False %>

Ein guter Grund für die Verwendung dieser Anweisung ist das interessante Problem, das bei Session-Objekten mit Framesets auftritt. ASP garantiert, dass zu einem bestimmten Zeitpunkt nur eine Anforderung von einem Session-Objekt ausgeführt wird. Wenn ein Browser für einen Benutzer mehrere Seiten anfordert, wird dadurch garantiert, dass zu einem bestimmten Zeitpunkt nur eine ASP-Anforderung beim Session-Objekt eingeht. Dadurch werden beim Zugreifen auf das Session-Objekt Multithread-Probleme vermieden. Dies führt jedoch auch dazu, dass alle Seiten in einem Frameset serialisiert, d. h. nacheinander statt simultan, gezeichnet werden. Der Benutzer muss daher u. U. lange warten, bis alle Frames angezeigt werden. Zusammenfasend gilt: Wenn bestimmte Frameset-Seiten nicht vom Session-Objekt abhängen, teilen Sie dies ASP mithilfe der Anweisung @EnableSessionState=False auf jeden Fall mit.  

Anstelle des Session-Objekts gibt es eine Reihe anderer Optionen zum Verwalten des Sitzungszustands. Für geringe Zustandsmengen (weniger als 4 KB) empfehlen sich Cookies, QueryString-Variablen und Variablen mit verborgenen Formularen. Für größere Datenmengen, wie z. B. Einkaufswagen, ist eine Back-End-Datenbank die beste Lösung. Es gibt viele Artikel über Zustandsverwaltungsmethoden in Webservergruppen. Weitere Einzelheiten finden Sie in den Referenzen zum Sitzungszustand.

Hier ist ein kurzer Tipp für Sie. Im Allgemeinen sollten Ressourcen spät abgerufen und früh freigegeben werden. Dies gilt sowohl für COM-Objekte als auch für Dateihandles und andere Ressourcen.  

ADO-Verbindungen und -Recordsets sind die besten Kandidaten für diese Optimierung. Wenn Sie ein Recordset nicht mehr benötigen, z. B. nachdem Sie eine Tabelle anhand der enthaltenen Daten erstellt haben, geben Sie sie sofort frei, statt zu warten, bis das Seitenende erreicht wird. Legen Sie die VBScript-Variable gewohnheitsmäßig auf Nothing fest. Lassen Sie das Recordset nicht einfach aus dem Gültigkeitsbereich herausfallen. Geben Sie außerdem alle verwandten Command- oder Connection-Objekte frei (Vergessen Sie nicht die Funktion Close() für Recordsets oder Connection-Objekte aufzurufen, bevor Sie diese auf = Nothing festlegen.) Dadurch wird der Zeitraum verkürzt, in dem die Datenbank Ressourcen für Sie jonglieren muss, und die Datenbankverbindung wird sobald wie möglich an den Verbindungs-Pool freigegeben.

Verwenden Sie Option Explicit in Ihren ASP-Dateien Wenn diese Anweisung am oberen Rand von ASP-Dateien positioniert wurde, muss der Entwickler alle zu verwendenden Variablen deklarieren. Viele Programmierer finden dies beim Debuggen von Anwendungen hilfreich, denn dadurch ist die Gefahr von Tippfehlern und das daraus resultierende versehentliche Erstellen neuer Variablen wesentlich geringer (z. B. MyXLMString=… anstatt MyXMLString=).  

Es ist aber vielleicht von noch größerer Wichtigkeit, dass deklarierte Variablen schneller sind als undeklarierte. Die Skriptlaufzeit verweist nämlich hinter den Kulissen auf undeklarierte Variablen anhand des Namens, jedes Mal, wenn sie verwendet werden. Deklarierten Variablen wird dagegen entweder zur Kompilierzeit oder zur Laufzeit eine Ordinalzahl zugewiesen. Im Folgenden wird auf deklarierte Variablen anhand dieser Ordinalzahl verwiesen. Da Option Explicit die Deklaration von Variablen erzwingt, stellt sie sicher, dass alle Variablen deklariert werden und somit schnell auf sie zugegriffen werden kann.