ASP Tipp 6: Verwenden Sie das „Session“-Objekt mit Umsicht

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.

 

ASP Tipp 7: Verkapseln Sie Code in COM-Objekten

Wenn Sie VBScript oder JScript vermehrt verwenden, können Sie in vielen Fällen die Leistung verbessern, indem Sie den Code in ein kompiliertes COM-Objekt verschieben. Kompilierter Code wird normalerweise schneller ausgeführt als interpretierter Code. Kompilierte COM-Objekte können über die „Auflösung zur Kompilierungszeit“, eine effizientere Methode zum Aufrufen von COM-Objektmethoden als die vom Skript verwendete „Auflösung zur Laufzeit“, auf andere COM-Objekte zugreifen.

Das Verkapseln von Code in COM-Objekten hat (abgesehen von der Leistung) einige Vorteile.

  1. COM-Objekt eignen sich gut zum Trennen der Präsentationslogik von der Geschäftslogik.
  2. COM-Objekte ermöglichen die Wiederverwendung von Code.
  3. Vielen Entwicklern füllt das Debuggen von Code, der in VB, C++ oder Visual J++ geschrieben wurde, leichter als das Debuggen von ASP.  

COM-Objekte haben Nachteile, darunter die anfängliche Entwicklungszeit und der Bedarf an unterschiedlichen Programmierungskenntnissen. Beachten Sie, dass das Verkapseln kleiner ASP-Beträge eher zu Leistungseinbußen als Leistungssteigerungen führt. Dies ist normalerweise der Fall, wenn ein geringer Umfang an ASP-Code in ein COM-Objekt eingefügt wird. Hier macht der Aufwand beim Erstellen und Aufrufen des COM-Objekts die Vorteile des kompilierten Codes zunichte. Sie werden die ideale Kombination aus ASP-Skript und COM-Objektcode zum Produzieren der optimalen Leistung nur durch Ausprobieren finden. Beachten Sie, dass Microsoft die Leistung von Skripts und ADO in Windows 2000/IIS 5.0 im Vergleich zu Windows NTä 4.0/IIS 4.0 enorm verbessert hat. Aus diesem Grund hat sich der Leistungsvorteil von kompiliertem Code im Vergleich zu ASP-Code seit der Einführung von IIS 5.0 verringert.

Ausführliche Diskussionen über die Vor- und Nachteile der Verwendung von COM-Objekten in ASP finden Sie in folgenden Dokumenten: „ASP Component Guidelines“ und „Programming Distributed Applications with COM and Microsoft Visual Basic 6.0“. Wenn Sie COM-Komponenten bereitstellen, müssen Sie diese unbedingt Belastungstests unterzogen werden. Im Prinzip sollten alle ASP-Anwendungen automatisch einem Belastungstest unterzogen werden.

 

Tipp 8: Rufen Sie Ressourcen spät ab, aber geben Sie sie früh frei

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.

 

ASP Tipp 9: Eine prozessexterne Ausführung gibt der Leistung auf Kosten der Zuverlässigkeit den Vorzug

Sowohl ASP als auch MTS/COM+ enthalten Konfigurationsoptionen, mit denen Sie einen Kompromiss zwischen Zuverlässigkeit und Leistung erzielen. Sie müssen sich beim Erstellen und Bereitstellen Ihrer Anwendung über diese Kompromisse im Klaren sein.  

ASP-Optionen

Sie können ASP-Anwendungen so konfigurieren, dass sie auf eine von drei Arten ausgeführt werden. In IIS 5.0 wurde der Begriff „Isolationsstufe“ zum Beschreiben dieser Optionen eingeführt. Es gibt drei Werte für die Isolationsstufe: Niedrig, Mittel und Hoch:

  1. Niedrige Isolation. Diese Option ist die schnellste und wird in allen Versionen von IIS unterstützt. Sie führt ASP in Inetinfo.exe, dem primären IIS-Prozess, aus. Wenn die ASP-Anwendung abstürzt, stürzt auch IIS ab. (Um IIS unter IIS 4.0 neu zu starten, überwachen Webmaster die Site mit Tools, wie z. B. InetMon, und lösen Stapeldateien aus, um einen ausgefallenen Server neu zu starten. In IIS 5.0 wird ein zuverlässiger Neustart eingeführt, der einen ausgefallenen Server automatisch neu startet.) 
  2. Mittlere Isolation. Diese neue Stufe wird in IIS 5.0 eingeführt. Sie wird auch als prozessexterne Stufe bezeichnet, da ASP außerhalb des IIS-Prozess ausgeführt wird. Bei der mittleren Isolation ist allen ASP-Anwendungen, die laut Konfiguration mit einer mittleren Isolationsstufe ausgeführt werden, der gleiche Prozessbereich gemeinsam. Dadurch werden zum Ausführen von mehreren prozessexternen ASP-Anwendungen in einem Feld weniger Prozesse benötigt. Mittel ist die Standardisolationsstufe in IIS 5.0.
  3. Hohe Isolation. Die in IIS 4.0 und IIS 5.0 unterstützte hohe Isolation ist ebenfalls prozessextern. Sollte ASP abstürzen, stürzt der Webserver nicht gleichzeitig ab. Die ASP-Anwendung wird bei der nächsten ASP-Anfrage automatisch neu gestartet. Bei der hohen Isolation wird jede ASP-Anwendung, die laut Konfiguration mit einer hohen Isolationsstufe ausgeführt wird, in ihrem eigenen Prozessbereich ausgeführt. Dadurch werden ASP-Anwendungen voneinander geschätzt. Der Nachteil ist, dass für jede ASP-Anwendung ein separater Prozess nötig ist. Wenn Dutzende von Anwendungen das gleiche Feld als Host verwenden, kann sich der Aufwand wesentlich erhöhen.  

Welche Option ist die Beste? In IIS 4.0 hatten prozessexterne Ausführungen starke Leistungseinbußen zur Folge. In IIS 5.0 haben wir uns bemüht, die Kosten einer prozessexternen Ausführung von ASP-Anwendungen zu minimieren. In den meisten Tests liefen prozessexterne ASP-Anwendungen in IIS 5.0 schneller als prozessinterne Anwendungen in IIS 4.0. Unabhängig davon bietet eine prozessinterne Ausführung (niedrige Isolationsstufe) auf beiden Plattformen auch weiterhin die beste Leistung. Eine niedrige Isolationsstufe bringt aber nicht besonders viele Vorteile, wenn die Trefferrate oder der maximale Durchsatz relativ niedrig sind. Aus diesem Grund sollten Sie die niedrige Isolationsstufe erst benötigen, wenn pro Webserver mehrere Tausend Seiten pro Sekunden benötigt werden. Testen Sie die verschiedenen Optionen für mehrere Konfigurationen, um herauszufinden, welche Kompromisse Sie einzugehen bereit sind.  

Anmerkung Wenn Sie ASP-Anwendungen prozessextern (mit mittlerer oder hoher Isolation) ausführen, werden Sie in MTS auf NT4 und COM+ auf Windows 2000 ausgeführt, d. h. auf NT4 werden sie in Mtx.exe und auf Windows 2000 in DllHost.exe ausgeführt. Die Ausführung dieser Prozesse ist im Task-Manager zu sehen. Sie können auch sehen, wie IIS MTS-Pakete oder COM+-Anwendungen für prozessexterne ASP-Anwendungen konfiguriert.  

COM-Optionen

Für COM-Komponenten gibt es ebenfalls drei Konfigurationsoptionen, die den ASP-Optionen jedoch nicht genau entsprechen. Für COM-Komponenten gibt es folgende Optionen: unkonfiguriert, als Bibliotheksanwendungen konfiguriert oder als Serveranwendungen konfiguriert. Unkonfiguriert bedeutet, dass die Komponente nicht in COM+ registriert ist. Diese Komponente wird im Prozessbereich des Aufrufers ausgeführt, d. h. sie ist „prozessintern“. Bibliotheksanwendungen sind ebenfalls prozessintern, profitieren aber von den COM+-Diensten, darunter Sicherheit, Transaktionen und Kontextunterstützung. Serveranwendungen sind so konfiguriert, dass sie in ihrem eigenen Prozessbereich ausgeführt werden. 

Unkonfigurierte Komponenten haben möglicherweise einen geringen Vorteil gegenüber Bibliotheksanwendungen. Der Leistungsvorteil von Bibliotheksanwendungen im Vergleich zu Serveranwendungen ist jedoch wesentlich deutlicher. Grund hierfür ist, dass Bibliotheksanwendungen im gleichen Prozess wie ASP, Serveranwendungen dagegen aber in ihrem eigenen Prozess ausgeführt werden. Prozessübergreifende Aufrufe sind kostspieliger als prozessinterne Aufrufe. Beim Weiterleiten von Daten wie z. B. Recordsets zwischen Prozessen müssen alle Daten zwischen beiden Prozessen kopiert werden.  

Großer Nachteil! Wenn Sie beim Verwenden von COM-Serveranwendungen Objekte zwischen ASP und COM weiterleiten, stellen Sie sicher, dass „Marshalling nach Wert“ (marshal-by-value, MBV) implementiert ist. Objekte, die MBV implementieren, kopieren sich selbst von einem Prozess zu einem anderen. Dies ist besser als die Alternative, bei der das Objekt im Erstellerprozess verbleibt und der andere Prozess wiederholt in den Erstellungsprozess eingreift, um das Objekt zu verwenden. Abgetrennte ADO-Recordsets marshallen nach Wert, verbundene Recordsets nicht. Das Scripting.Dictionary-Objekt implementiert MBV nicht und sollte nicht zwischen Prozessen weitergegeben werden. Zum Schluss noch ein Rat für alle VB-Programmierer: MBV wird NICHT durch Weitergabe eines ByVal-Parameters erzielt, sondern vom ursprünglichen Komponentenverfasser implementiert.  

Vorgehensweise

Wenn wir Konfigurationen mit akzeptablen Kompromissen zwischen Leistung und Zuverlässigkeit empfehlen sollten, würden diese wie folgt lauten:

  1. Verwenden Sie in IIS 4.0 die niedrige Isolationsstufe sowie MTS-Serverpakete. 
  2. Verwenden Sie in IIS 5.0 die mittlere Isolationsstufe sowie COM+-Bibliotheksanwendungen.  

Hierbei handelt es sich um sehr allgemeine Richtlinien. Hostunternehmen führen ASP in der Regel mit einer mittleren oder hohen Isolationsstufe aus, wohingegen Webserver mit nur einem Zweck mit einer niedrigen Isolation ausgeführt werden können. Ermitteln Sie die Kompromisse, und entscheiden Sie dann, welche Konfiguration Ihren Bedürfnissen entspricht.

 

ASP Tipp 10: Verwenden Sie „Option Explicit“

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.

 

ASP Tipp 11: Verwenden Sie lokale Variablen in Subroutinen und Funktionen

Bei lokalen Variablen handelt es sich um Variablen, die in Subroutinen und Funktionen deklariert wurden. In einer Funktion oder Subroutine ist der Zugriff auf lokale Variablen schneller als der Zugriff auf globale Variablen. Durch lokale Variablen ist Code außerdem übersichtlicher. Daher sollten Sie diese, wenn möglich, verwenden.

 

ASP Tipp 12: Kopieren Sie häufig verwendete Daten in Skriptvariablen

Beim Zugriff auf COM-Objekte in ASP sollten Sie häufig verwendete Objektdaten in Skriptvariablen kopieren. Dadurch werden die im Vergleich zum Zugriff auf Skriptvariablen relativ kostspieligen COM-Methodenaufrufe reduziert. Beim Zugreifen auf Collection- und Dictionary-Objekte reduziert diese Methode außerdem teure Suchen.

Wenn Sie mehrmals auf Objektdaten zugreifen, sollten Sie sie im Allgemeinen in einer Skriptvariablen ablegen. Request-Variablen (Form- oder QueryString-Variablen) sind für diese Optimierung ideal. Ihre Site gibt z. B. eine QueryString-Variable namens UserID weiter. Angenommen auf diese UserID wird auf einer bestimmten Seite ein Dutzend Mal verwiesen. Weisen Sie die UserID am oberen Rand der ASP-Seite einer Variablen zu, anstatt Request(„UserID“) ein Dutzend Mal aufzurufen, und verwenden Sie diese Variable dann überall auf der Seite. Damit sparen Sie 11 COM-Methodenaufrufe.

In der Praxis kann der Zugriff auf COM-Eigenschaften und -Methoden unerwartet kostspielig sein. Das folgende Beispiel enthält (syntaktisch gesprochen) ziemlich gängigen Code:

Foo.bar.blah.baz = Foo.bar.blah.qaz(1)

If Foo.bar.blah.zaq = Foo.bar.blah.abc Then ‚ …

Beim Ausführen des Codes geschieht Folgendes:

  1. Die Variable Foo wird als globales Objekt aufgelöst.
  2. Die Variable bar wird als Mitglied von Foo aufgelöst. Dies ist ein COM-Methodenaufruf.
  3. Die Variable blah wird als Mitglied von Foo.bar aufgelöst und ist ebenfalls ein COM-Methodenaufruf.
  4. Die Variable qaz wird als Mitglied von foo.bar.blah aufgelöst, und dies ist ebenfalls ein COM-Methodenaufruf.
  5. Rufen Sie Foo.bar.blah.quaz(1) auf. Es wird ein weiterer COM-Methodenaufruf ausgeführt. Alles klar?
  6. Wiederholen Sie Schritt 1 bis 3, um baz aufzulösen. Das System weiß nicht, ob das Objektmodell durch den Aufruf von qaz geändert wurde. Deshalb müssen die Schritte 1 bis 3 wiederholt werden, um baz aufzulösen.
  7. Lösen Sie baz als Mitglied von Foo.bar.blah auf. Fähren Sie die Eigenschafteneingabe aus.
  8. Wiederholen Sie Schritt 1 bis 3, um zaq aufzulösen.
  9. Wiederholen Sie Schritt 1 bis 3, um abc aufzulösen.

Wie Sie sehen, ist dies unheimlich ineffizient (und langsam). Um diesen Code schnell in VBScript zu schreiben, verwenden Sie Folgendes:

Set myobj = Foo.bar.blah ‚ do the resolution of blah ONCE

Myobj.baz = myobj.qaz(1)

If Myobj.zaq = Myobj.abc Then ‚…

Wenn Sie VBScript 5.0 oder höher verwenden, können Sie beim Schreiben die With-Anweisung verwenden.

With Foo.bar.blah

.baz = .qaz(1)

If .zaq = .abc Then ‚…

End With

Dieser Tipp gilt auch für das Programmieren mit VB.

ASP Tipp 13: Vermeiden das Neudimensionieren von Arrays

Vermeiden Sie nach Möglichkeit das Neudimensionieren von Arrays mit Redim. Wenn die physikalische Speichergröße Ihres Computer eingeschränkt ist, empfiehlt es sich in Bezug auf die Leistung, die Anfangsdimension des Arrays auf das schlimmste Szenario festzulegen. Sie können die Dimension auch für das optimale Szenario einstellen und bei Bedarf neu festlegen. Dies bedeutet nicht, dass Sie einfach ein paar Megabyte Arbeitsspeicher zuordnen sollen, wenn Sie wissen, dass er nicht gebraucht wird.

Dieser Code zeigt den unnötigen Gebrauch von Dim und Redim.

<%

Dim MyArray()

Redim MyArray(2)

MyArray(0) = „hello“

MyArray(1) = „good-bye“

MyArray(2) = „farewell“

‚ some other code where you end up needing more space happens, then …

Redim Preserve MyArray(5)

MyArray(3) = „more stuff“

MyArray(4) = „even more stuff“

MyArray(5) = „yet more stuff“

%>

Es ist wesentlich besser, das Feld anfangs mit Dim auf die richtige Größe einzustellen (in diesem Fall 5), und es dann mit Redim zu vergrößern. Dabei verschwenden Sie eventuell etwas Speicher (wenn Sie nicht alle Elemente verwenden), gewinnen aber an Geschwindigkeit.

ASP Tipp 14: Verwenden Sie den Antwortpuffer

Sie können eine ganze auszugebende Seite durch Aktivieren des „Antwortpuffers“ puffern. Dadurch wird die Anzahl der Schreibvorgänge im Browser reduziert und die Gesamtleistung gesteigert. Für jeden Schreibvorgang ist ein großer Aufwand nötig (sowohl in IIS und bezüglich der über die Leitung gesendeten Datenmengen), d. h. je weniger Leitungen, desto besser. TCP/IP funktioniert aufgrund seines langsamen Starts und der Nagling-Algorithmen (zum Minimieren von Netzwerkstaus) effizienter, wenn anstelle von vielen kleinen Datenblöcken wenige große Datenblöcke gesendet werden können.

Sie können den Antwortpuffer auf zwei Arten aktivieren. Einerseits können Sie den Antwortpuffer mit dem Internetdienste-Manager für die gesamte Anwendung aktivieren. Diese Methode wird empfohlen. Der Antwortpuffer wird in IIS 4.0 und IIS 5.0 standardmäßig für neue ASP-Anwendungen aktiviert. Andererseits können Sie den Antwortpuffer auf Seitenbasis aktivieren, indem Sie folgende Codezeile am oberen Rand der ASP-Seite positionieren.

<% Response.Buffer = True %>

Diese Codezeile muss ausgeführt werden, bevor Antwortdaten in den Browser geschrieben werden (d. h., bevor HTML im ASP-Skript angezeigt wird, und bevor Cookies mit der Response.Cookies-Auflistung festgelegt wurden). Im Allgemeinen sollten Sie den Antwortpuffer für die ganze Anwendung aktivieren. Damit ist die obige Codezeile auf jeder Seite überflüssig.

Response.Flush

Benutzer sind häufig der Meinung, dass die Antwortzeit von ASP-Seiten durch den Antwortpuffer langsamer ist (obwohl die Antwortzeit insgesamt verbessert ist), weil sie warten müssen, bis die gesamte Seite generiert wurde, bevor eine Anzeige erfolgt. Sie können den Antwortpuffer für lange Seiten deaktivieren, indem Sie Response.Buffer = False festlegen. Es gibt aber eine bessere Strategie: Verwenden Sie stattdessen die Response.Flush-Methode, bei der ASP den gesamten gezeichneten HTML-Inhalt im Browser anzeigt. Nachdem z. B. 100 Zeilen einer aus 1000 Zeilen bestehenden Tabelle gezeichnet wurden, kann ASP Response.Flush aufrufen, um die gezeichneten Ergebnisse im Browser anzuzeigen. Damit kann der Benutzer die ersten 100 Zeilen sehen, bevor die verbleibenden Zeilen fertig sind. Diese Methode bietet Ihnen das Beste aus beiden Bereichen: den Antwortpuffer in Kombination mit der allmählichen Präsentation der Daten im Browser.

(Beachten Sie, dass viele Browser beim oben dargestellten Beispiel einer aus 1000 Zeilen bestehenden Tabelle die Tabelle erst anzeigen, wenn sie das schließende Kennzeichen </table> sehen. Präfen Sie, ob die gewünschten Browser die teilweise Anzeige unterstützen. Sie können dieses Problem umgehen, indem Sie die Tabelle in mehrere Tabellen mit einer geringeren Anzahl von Zeilen aufteilen und nach jeder Tabelle Response.Flush aufrufen. Neuere Versionen von Internet Explorer zeigen Tabellen an, bevor sie vollständig gedownloadet wurden, und die Anzeige erfolgt besonders schnell, wenn sie die Spaltenbreiten der Tabelle festlegen. Dadurch braucht Internet Explorer die Spaltenbreiten nicht durch Messen des Inhalts jeder einzelnen Zelle zu berechnen.)  

Benutzer beschweren sich beim Antwortpuffer außerdem darüber, dass er beim Generieren sehr großer Seiten sehr viel Serverspeicher verbraucht. Ohne hier Weisheiten über das Generieren von sehr großen Seiten abzugeben, lässt sich dieses Problem ebenfalls mithilfe von Response.Flush beheben.

 

ASP Tipp 15: Stapeln Sie Inlineskripts und Response.Write-Anweisungen

Die VBScript-Syntax <% = expression %> schreibt die Werte von „expression“ in den ASP-Ausgabestrom. Wenn der Antwortpuffer nicht aktiviert ist, schreiben alle diese Anweisungen Daten in vielen kleinen Paketen über das Netzwerk in den Browser. Dies geht nur langsam vonstatten. Außerdem führt das Abwechseln von kleinen Skript- und HTML-Mengen zu einem Wechsel zwischen dem Skriptmodul und HTML, was sich ebenfalls negativ auf die Leistung auswirkt. Halten Sie sich daher an folgenden Tipp: Ersetzen Sie eng gepackte Inlineanweisungen durch einen Aufruf von Response.Write. Im folgenden Beispiel erfolgt pro Feld und Zeile ein Schreibvorgang im Antwortstrom, und pro Zeile finden viele Wechsel zwischen VBScript und HTML statt.

<table>

<% For Each fld in rs.Fields %>

<th><% = fld.Name %></th>

<%

Next

While Not rs.EOF

%>

<tr>

<% For Each fld in rs.Fields %>

<td><% = fld.Value %></td>

<% Next

</tr>

<% rs.MoveNext

Wend %>

</table>

Im effizienteren Code weiter unten erfolgt pro Zeile ein Schreibvorgang im Antwortstrom. Der gesamte Code ist in einem VBScript-Block enthalten:

<table>

<%

For each fld in rs.Fields

Response.Write („<th>“ & fld.Name & „</th>“ & vbCrLf)

Next

While Not rs.EOF

Response.Write („<tr>“)

For Each fld in rs.Fields %>

Response.Write(„<td>“ & fld.Value & „</td>“ & vbCrLf)

Next

Response.Write „</tr>“

Wend

%>

</table>

Dieser Tipp hat wesentlich stärkere Auswirkungen, wenn der Antwortpuffer deaktiviert ist. Es empfiehlt sich, den Antwortpuffer zu aktivieren, und auszuprobieren, ob die Leistung durch Stapelverarbeitung von Response.Write verbessert werden kann.

(In diesem speziellen Beispiel kann die verschachtelte Schleife, die den Tabellenkörper erstellt (While Not rs.EOF…), durch einen gut durchdachten Aufruf von GetString), ersetzt werden.)