ASP-Entwickler sind ständig bestrebt, in ihren Designprojekten eine bessere Leistung und Skalierbarkeit zu erreichen. Glücklicherweise gibt es viele Bücher und Websites, die gute Ratschläge in diesem Bereich bieten. Diese Vorschläge basieren jedoch auf Schlussfolgerungen aus der Struktur der Arbeit der ASP-Plattform und es gibt keine quantitative Messung der tatsächlichen Leistungsverbesserung. Da diese Empfehlungen eine komplexere Codierung erfordern und die Lesbarkeit des Codes beeinträchtigen, müssen Entwickler abwägen, ob sich die Verbesserung der Leistung ihrer ASP-Anwendungen lohnt, ohne tatsächliche Ergebnisse zu sehen.
Dieser Artikel ist in zwei Teile gegliedert, um Entwicklern dabei zu helfen, festzustellen, ob sich eine bestimmte Initiative nicht nur für zukünftige Projekte, sondern auch für die Aktualisierung des ursprünglichen Projekts lohnt. Im ersten Teil werde ich einige grundlegende Aspekte der ASP-Entwicklung besprechen. Im zweiten Teil befassen Sie sich mit der Optimierung einiger ADO-Funktionen und dem Vergleich ihrer Ergebnisse mit ASP-Seiten, die VB-COM-Objekte aufrufen, um dieselben ADO-Funktionen auszuführen. Die Ergebnisse sind aufschlussreich und manchmal überraschend.
In diesem Artikel beantworten wir die folgenden Fragen:
* Was ist der effizienteste Weg, ASP-generierte Inhalte in den Antwortstream zu schreiben?
* Sollte der Puffer aktiviert sein?
* Sollten Sie erwägen, Kommentare zu Ihrem ASP-Code hinzuzufügen?
* Sollte die Standardsprache explizit für die Seite festgelegt werden?
* Sollte der Sitzungsstatus geschlossen sein, wenn er nicht benötigt wird?
* Sollte Skriptlogik in Unterprogrammen und Funktionsbereichen platziert werden?
* Welche Auswirkungen hat die Verwendung von Include-Dateien?
* Welche Belastung entsteht bei der Fehlerbehandlung?
* Hat das Einrichten eines Kontexthandlers Auswirkungen auf die Leistung?
Alle Tests wurden mit dem Web Application Focus Tool (WAST) von Microsoft durchgeführt, einem kostenlosen Tool, das hier gefunden werden kann. Ich habe mit WAST ein einfaches Testskript erstellt, das die unten beschriebenen ASP-Seitentests wiederholt aufruft (jeweils über 70.000 Mal). Die Antwortzeit basiert auf der durchschnittlichen Gesamtzeit des letzten Bytes (TTLB), also der Zeit vom Zeitpunkt der ersten Anfrage bis zum Zeitpunkt, an dem das Tool das letzte Datenbit vom Server empfängt. Unser Testserver ist ein Pentium 166 mit 196 MB RAM und der Client ist ein Pentium 450 mit 256 MB RAM. Sie denken vielleicht, dass die Leistung dieser Maschinen nicht sehr hoch ist, aber vergessen Sie nicht, dass wir nicht die Kapazität des Servers testen, sondern nur die Zeit, die der Server benötigt, um jeweils eine Seite zu verarbeiten. Während des Tests verrichten die Maschinen keine weiteren Arbeiten. Die WAST-Testskripte, Testberichte und alle ASP-Testseiten sind in der ZIP-Datei enthalten, damit Sie sie selbst überprüfen und testen können.
Was ist der effizienteste Weg, ASP-generierte Inhalte in den Antwortstream zu schreiben?
Einer der Hauptgründe für die Verwendung von ASP ist die Generierung dynamischer Inhalte auf dem Server. Der offensichtliche Ausgangspunkt für unsere Tests besteht also darin, die am besten geeignete Methode zum Senden dynamischer Inhalte in den Antwortstream zu ermitteln. Von den vielen Optionen sind zwei die grundlegendsten: Eine besteht darin, Inline-ASP-Tags zu verwenden, und die andere darin, die Response.Write-Anweisung zu verwenden.
Um diese Optionen zu testen, haben wir eine einfache ASP-Seite erstellt, in der wir einige Variablen definiert und dann ihre Werte in eine Tabelle eingefügt haben. Obwohl diese Seite einfach und nicht sehr praktisch ist, ermöglicht sie uns, einige einzelne Probleme zu isolieren und zu testen.
Verwendung von ASP-Inline-Tags
Der erste Test umfasst die Verwendung des Inline-ASP-Tags < %= x % >, wobei x eine zugewiesene Variable ist. Diese Methode ist bei weitem am einfachsten durchzuführen und sorgt dafür, dass der HTML-Teil der Seite in einem Format bleibt, das leicht zu lesen und zu verwalten ist.
<% OPTION EXPLICIT
Vorname abdunkeln
DimLastName
Dim MiddleInitial
Dunkle Adresse
Dunkle Stadt
Schwacher Zustand
DimPhoneNumber
Faxnummer dimmen
E-Mail dimmen
DimBirthDate
Vorname = John
MiddleInitial = Q
Nachname = Öffentlich
Adresse = 100 Main Street
Stadt=New York
Bundesstaat=NY
Telefonnummer = 1-212-555-1234
Faxnummer = 1-212-555-1234
E-Mail = [email protected]
Geburtsdatum = 1.1.1950
%>
<HTML>
<KOPF>
＜ TITEL ＞Antworttest ＜ / TITEL ＞
＜ /KOPF ＞
<KÖRPER>
＜ H1 ＞Antworttest ＜ /H1 ＞
＜ TABELLE ＞
＜ tr ＞＜ td ＞＜ b ＞Vorname:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Vorname % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Middle Initial:＜ /b ＞＜ /td ＞＜ td ＞＜ %= MiddleInitial % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Nachname:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Nachname % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Adresse:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Adresse % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Stadt:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Stadt % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞State:＜ /b ＞＜ /td ＞＜ td ＞＜ %= State % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Telefonnummer:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Telefonnummer % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Faxnummer:＜ /b ＞＜ /td ＞＜ td ＞＜ %= FaxNumber % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞EMail:＜ /b ＞＜ /td ＞＜ td ＞＜ %= EMail % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Geburtsdatum:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Geburtsdatum % ＞＜ /td ＞＜ /tr ＞
＜ /TABELLE ＞
＜ /KÖRPER ＞
＜ /HTML ＞
Der vollständige Code von /app1/response1.asp
Bisherige Bestleistung (Antwortgeschwindigkeit) = 8,28 ms/Seite
Verwenden Sie die Response.Write-Anweisung für jede HTML-Zeile
Viele der besseren Lerndokumente empfehlen, die vorherige Methode zu vermeiden. Der Hauptgrund hierfür liegt darin, dass bei der Ausgabe der Seite und der Verarbeitung der Seite, um Latenz zu verursachen, ein Problem auftritt, das als Kontextwechsel bezeichnet wird, wenn der Webserver zwischen dem Senden von reinem HTML und der Verarbeitung von Skripten konvertieren muss. Wenn die meisten Programmierer das hören, besteht ihre erste Reaktion darin, jede Zeile rohen HTML-Codes in eine Response.Write-Funktion zu packen.
…
Response.Write(＜html＞)
Response.Write(＜head＞)
Response.Write(＜title＞Response Test＜/title＞)
Response.Write(＜/head＞)
Response.Write(＜body＞)
Response.Write(＜h1＞Antworttest＜/h1＞)
Response.Write(＜table＞)
Response.Write(＜ tr ＞＜ td ＞＜ b ＞Vorname:＜ /b ＞＜ /td ＞＜ td ＞ & Vorname & ＜ /td ＞＜ /tr ＞)
Response.Write(＜ tr ＞＜ td ＞＜ b ＞Middle Initial:＜ /b ＞＜ /td ＞＜ td ＞ & MiddleInitial & ＜ /td ＞＜ /tr ＞)
… <
Fragment von /app1/response2.asp
Bisherige Bestleistung (Antwortgeschwindigkeit) = 8,28 ms/Seite
Reaktionszeit = 8,08 ms/Seite
Differenz = -0,20 ms (2,4 % Reduzierung)
Wir können sehen, dass der Leistungsgewinn durch die Verwendung dieses Ansatzes im Vergleich zur Verwendung von Inline-Markup sehr gering ist, möglicherweise weil die Seite den Server mit einer Reihe kleiner Funktionsaufrufe belastet. Der größte Nachteil dieses Ansatzes besteht darin, dass der Skriptcode ausführlicher und schwieriger zu lesen und zu warten ist, da der HTML-Code nun in das Skript eingebettet ist.
Verwenden Sie Wrapper-Funktionen
Die vielleicht entmutigendste Entdeckung beim Versuch, den Response.Write-Anweisungsansatz zu verwenden, ist, dass die Response.Write-Funktion nicht am Ende jeder Zeile ein CRLF platzieren kann. Wenn Sie also den Quellcode im Browser lesen, besteht der perfekt gestaltete HTML-Code nun aus einer Zeile ohne Ende. Ich denke, Ihre nächste Entdeckung könnte noch erschreckender sein: Es gibt keine Schwesterfunktion Writeln im Response-Objekt. Eine naheliegende Reaktion besteht also darin, eine Wrapper-Funktion für die Response.Write-Funktion zu erstellen, um an jede Zeile ein CRLF anzuhängen.
…
writeCR(＜ tr ＞＜ td ＞＜ b ＞Vorname:＜ /b ＞＜ /td ＞＜ td ＞ & Vorname & ＜ /td ＞＜ /tr ＞)
…
SUB writeCR(str)
Response.Write(str & vbCRLF)
ENDE SUB
Fragment von /app1/response4.asp
Bisherige Bestleistung (Antwortgeschwindigkeit) = 8,08 ms/Seite
Reaktionszeit = 10,11 ms/Seite
Differenz = +2,03 ms (25,1 % Anstieg)
Da dieser Ansatz die Anzahl der Funktionsaufrufe effektiv verdoppelt, hat er natürlich erhebliche Auswirkungen auf die Leistung und sollte unbedingt vermieden werden. Ironischerweise fügt CRLF dem reaktiven Stream auch 2 Bytes pro Zeile hinzu, die der Browser nicht auf der Seite rendern muss. Gut formatiertes HTML macht es Ihren Konkurrenten lediglich einfacher, Ihren HTML-Quellcode zu lesen und Ihr Design zu verstehen.
Verketten Sie aufeinanderfolgende Response.Write zu einer einzigen Anweisung
Unabhängig von unseren vorherigen Tests mit Wrapper-Funktionen besteht der nächste logische Schritt darin, alle Zeichenfolgen aus den separaten Response.Write-Anweisungen zu extrahieren und sie in einer einzigen Anweisung zu verketten, wodurch die Anzahl der Funktionsaufrufe reduziert und die Leistung der Seite erheblich verbessert wird.
…
Response.Write(＜html＞&_
＜ Kopf ＞ & _
＜title＞Response Test＜/title＞ & _
＜ /head ＞ & _
<Körper> & _
＜ h1 ＞Antworttest＜ /h1 ＞ & _
＜ Tabelle ＞ & _
＜ tr ＞＜ td ＞＜ b ＞Vorname:＜ /b ＞＜ /td ＞＜ td ＞ & Vorname & ＜ /td ＞＜ /tr ＞ & _
…
＜ tr ＞＜ td ＞＜ b ＞Geburtsdatum:＜ /b ＞＜ /td ＞＜ td ＞ & Geburtsdatum & ＜ /td ＞＜ /tr ＞ & _
＜ /table ＞ & _
＜ /body ＞ & _
＜ /html ＞)
Fragment von /app1/response3.asp
Bisherige Bestleistung (Antwortgeschwindigkeit) = 8,08 ms/Seite
Reaktionszeit = 7,05 ms/Seite
Differenz = -1,03 ms (12,7 % Reduzierung)
Derzeit ist dies die am besten optimierte Konfiguration.
Verketten Sie aufeinanderfolgende Response.Write zu einer einzelnen Anweisung und fügen Sie am Ende jeder Zeile ein CRLF hinzu
Aus Rücksicht auf diejenigen, die möchten, dass ihr Quellcode in einem Browser makellos aussieht, habe ich im vorherigen Test die vbCRLF-Konstante verwendet, um am Ende jeder Zeile einige Wagenrückläufe einzufügen, und ihn erneut ausgeführt.
…
Response.Write(＜html＞&vbCRLF&_
＜ Kopf ＞ & vbCRLF & _
＜ title ＞Response Test＜ /title ＞ & vbCRLF & _
＜ /head ＞ & vbCRLF & _
…
Fragment von /app1/response5.asp
Bisherige Bestleistung (Antwortgeschwindigkeit) = 7,05 ms/Seite
Reaktionszeit = 7,63 ms/Seite
Differenz = +0,58 ms (8,5 % Anstieg)
Das Ergebnis ist ein leichter Leistungsabfall, möglicherweise aufgrund der zusätzlichen Verkettung und der erhöhten Anzahl von Zeichen.
Rückblick und Beobachtung
Einige Regeln lassen sich aus den vorherigen Tests zur ASP-Ausgabe ableiten:
* Vermeiden Sie den übermäßigen Einsatz von Inline-ASP.
* Verketten Sie aufeinanderfolgende Response.Write-Anweisungen immer zu einer einzigen Anweisung.
* Verwenden Sie niemals Wrapper-Funktionen rund um Response.Write, um CRLF anzuhängen.
* Wenn die HTML-Ausgabe formatiert werden muss, hängen Sie CRLF direkt in die Response.Write-Anweisung ein.
Sollte der Puffer aktiviert werden?
Puffer per Skript starten
Durch Einfügen von Response.Buffer=True oben im ASP-Skript speichert IIS den Inhalt der Seite zwischen.
<% OPTION EXPLICIT
Response.Buffer = true
Vorname abdunkeln
…
Fragment von /app1/buffer__1.asp
Bisherige Bestzeit (Reaktionszeit) = 7,05 ms/Seite
Reaktionszeit = 6,08 ms/Seite
Differenz = -0,97 ms (13,7 % Reduzierung)
Die Leistung wurde erheblich verbessert. Aber warten Sie, es gibt etwas Besseres.
Puffer über Serverkonfiguration starten
Obwohl der Puffer in IIS 5.0 standardmäßig aktiviert ist, muss er in IIS 4.0 manuell aktiviert werden. Suchen Sie nun das Dialogfeld „Eigenschaften“ der Site und wählen Sie auf der Registerkarte „Home-Verzeichnis“ die Schaltfläche „Konfigurieren“. Wählen Sie dann unter App-Optionen die Option Pufferung aktivieren aus. Für diesen Test wurde die Response.Buffer-Anweisung aus dem Skript verschoben.
Bisheriger Bestwert = 7,05 ms/Seite
Reaktionszeit = 5,57 ms/Seite
Differenz = -1,48 ms (21,0 % Reduzierung)
Derzeit ist dies die schnellste Antwort, die wir je hatten, 21 % kürzer als unsere bisherige Best-Case-Reaktionszeit. Von nun an werden unsere zukünftigen Tests diese Reaktionszeit als Basiswert verwenden.
Rückblick und Beobachtung
Puffer sind eine großartige Möglichkeit, die Leistung zu verbessern. Daher ist es erforderlich, die Puffer auf die Standardwerte des Servers festzulegen. Wenn die Seite den Puffer aus irgendeinem Grund nicht ordnungsgemäß ausführen kann, verwenden Sie einfach den Befehl Response.Buffer=False. Ein Nachteil von Puffern besteht darin, dass der Benutzer nichts vom Server sieht, bis die gesamte Seite verarbeitet wurde. Daher empfiehlt es sich, während der Verarbeitung komplexer Seiten gelegentlich Response.Flush aufzurufen, um den Benutzer zu aktualisieren.
Jetzt haben wir eine weitere Regel hinzugefügt: Aktivieren Sie die Pufferung immer über die Servereinstellungen.
Sollten Sie darüber nachdenken, Ihrem ASP-Code Kommentare hinzuzufügen?
Die meisten HTML-Entwickler wissen, dass das Einbinden von HTML-Kommentaren eine schlechte Idee ist, da es erstens die Größe der übertragenen Daten erhöht und zweitens anderen Entwicklern lediglich Informationen über die Organisation Ihrer Seite liefert. Aber was ist mit Kommentaren auf ASP-Seiten? Sie verlassen nie den Server, vergrößern aber die Größe der Seite und müssen daher mithilfe von ASP aufgelöst werden.
In diesem Test haben wir 20 Kommentare mit jeweils 80 Zeichen hinzugefügt, also insgesamt 1.600 Zeichen.
<% OPTION EXPLICIT
'------------------------------------------------ - ---------------------------------
…20 Zeilen…
'------------------------------------------------ - ---------------------------------
Vorname abdunkeln
…
/app2/comment_1.asp-Fragment
Grundlinie = 5,57 ms/Seite
Reaktionszeit = 5,58 ms/Seite
Differenz = +0,01 ms (0,1 % Anstieg)
Die Ergebnisse des Tests waren erstaunlich. Obwohl Kommentare fast doppelt so lang sind wie die Datei selbst, hat ihr Vorhandensein keinen großen Einfluss auf die Antwortzeiten. Daher können wir folgende Regeln befolgen:
Solange ASP-Anmerkungen mäßig verwendet werden, haben sie kaum oder gar keine Auswirkungen auf die Leistung.
Sollte die Standardsprache explizit für die Seite festgelegt werden?
IIS verarbeitet standardmäßig VBScript, aber ich sehe, dass die Sprache in den meisten Fällen mithilfe der Anweisung <%@LANGUAGE=VBSCRIPT%> explizit auf VBScript festgelegt wird. Unser nächster Test wird untersuchen, welche Auswirkungen das Vorhandensein dieser Erklärung auf die Leistung hat.
＜ %@ LANGUAGE=VBSCRIPT % ＞
<% OPTION EXPLICIT
Vorname abdunkeln
…
/app2/sprache1.asp-Fragment.
Grundlinie = 5,57 ms/Seite
Reaktionszeit = 5,64 ms/Seite
Differenz = +0,07 ms (1,2 % Anstieg)
Wie Sie sehen, hat die Einbeziehung von Sprachdeklarationen einen leichten Einfluss auf die Leistung. daher:
* Stellen Sie die Standardsprachenkonfiguration des Servers so ein, dass sie mit der auf der Site verwendeten Sprache übereinstimmt.
* Legen Sie keine Sprachdeklaration fest, es sei denn, Sie verwenden eine Nicht-Standardsprache.
Sollte der Sitzungsstatus deaktiviert werden, wenn er nicht benötigt wird?
Es gibt viele Gründe, die Verwendung des IIS-Sitzungskontexts zu vermeiden, und diese könnten ein eigener Artikel sein. Die Frage, die wir jetzt zu beantworten versuchen, ist, ob das Schließen des Sitzungskontexts, wenn er von der Seite nicht benötigt wird, zur Verbesserung der Leistung beiträgt. Theoretisch sollte dies „Ja“ sein, da dann keine Notwendigkeit besteht, die Seite zum Instanziieren des Sitzungskontexts zu verwenden.
Wie beim Puffer gibt es zwei Möglichkeiten, den Sitzungsstatus zu konfigurieren: über Skripte und über Servereinstellungen.
Sitzungskontext per Skript schließen
Für diesen Test habe ich zum Schließen des Sitzungskontexts auf der Seite eine Sitzungsstatusdeklaration hinzugefügt.
＜ %@ ENABLESESSIONSTATE = FALSE % ＞
<% OPTION EXPLICIT
Vorname abdunkeln
…
/app2/session_1.asp-Fragment.
Grundlinie = 5,57 ms/Seite
Reaktionszeit = 5,46 ms/Seite
Differenz = -0,11 ms (2,0 % Abnahme)
Mit so einer kleinen Anstrengung konnten gute Fortschritte erzielt werden. Schauen Sie sich nun Teil zwei an.
Schließen Sie den Sitzungskontext über die Serverkonfiguration
Um den Sitzungskontext auf dem Server zu schließen, wechseln Sie zum Dialogfeld „Eigenschaften“ der Site. Wählen Sie auf der Registerkarte „Home-Verzeichnis“ die Schaltfläche „Konfiguration“. Deaktivieren Sie dann unter „App-Optionen“ das Kontrollkästchen „Sitzungsstatus aktivieren“. Wir führen den Test ohne die ENABLESESSIONSTATE-Anweisung aus.
Grundlinie = 5,57 ms/Seite
Reaktionszeit = 5,14 ms/Seite
Differenz = -0,43 ms (7,7 % Reduzierung)
Dies ist eine weitere deutliche Leistungsverbesserung. Daher sollte unsere Regel lauten: Schließen Sie den Sitzungsstatus immer auf Seiten- oder Anwendungsebene, wenn er nicht benötigt wird.
Wird die Verwendung von Option Explicit die Leistung erheblich verändern?
Legen Sie Option Explicit oben auf einer ASP-Seite fest, um zu verlangen, dass alle Variablen vor der Verwendung auf der Seite deklariert werden. Dafür gibt es zwei Gründe. Erstens können Anwendungen den Variablenzugriff schneller verarbeiten. Zweitens verhindert dies, dass wir Variablennamen versehentlich falsch verwenden. In diesem Test entfernen wir die Option Explicit-Referenz und die Dim-Deklaration der Variablen.
Grundlinie = 5,57 ms/Seite
Reaktionszeit = 6,12 ms/Seite
Differenz = +0,55 ms (9,8 % Anstieg),
Obwohl einige Codezeilen von der Seite entfernt wurden, erhöhten sich die Antwortzeiten dennoch. Obwohl die Verwendung der expliziten Option manchmal zeitaufwändig ist, hat sie erhebliche Auswirkungen auf die Leistung. Daher können wir eine weitere Regel hinzufügen: Verwenden Sie in VBScript immer die explizite Option.
Sollte Skriptlogik in Unterprogrammen und Funktionsbereichen platziert werden?
Die Verwendung von Funktionen und Unterprogrammen ist eine gute Möglichkeit, Code zu organisieren und zu verwalten, insbesondere wenn ein Codebereich mehrfach auf der Seite verwendet wird. Der Nachteil besteht darin, dass dem System ein zusätzlicher Funktionsaufruf hinzugefügt wird, der dieselbe Aufgabe erledigt. Ein weiteres Problem bei Unterprogrammen und Funktionen ist der Umfang von Variablen. Theoretisch ist es effizienter, Variablen innerhalb eines Funktionsbereichs anzugeben. Sehen wir uns nun an, wie diese beiden Aspekte zusammenkommen.
Verschieben Sie die Response.Write-Anweisung in eine Unterroutine
Dieser Test verschiebt einfach die Response.Write-Anweisung in einen Unterprogrammbereich.
…
CALL writeTable()
SUB writeTable()
Response.Write(＜html＞&_
＜ Kopf ＞ & _
…
＜ tr ＞＜ td ＞＜ b ＞EMail:＜ /b ＞＜ /td ＞＜ td ＞ & EMail & ＜ /td ＞＜ /tr ＞ & _
＜ tr ＞＜ td ＞＜ b ＞Geburtsdatum:＜ /b ＞＜ /td ＞＜ td ＞ & Geburtsdatum & ＜ /td ＞＜ /tr ＞ & _
＜ /table ＞ & _
＜ /body ＞ & _
＜ /html ＞)
ENDE SUB
/app2/function1.asp-Fragment
Grundlinie = 5,57 ms/Seite
Reaktionszeit = 6,02 ms/Seite
Differenz = +0,45 ms (8,1 % Anstieg)
Wie erwartet verursachen Unterprogrammaufrufe zusätzlichen Overhead auf der Seite.
Verschieben Sie alle Skripte in Unterroutinen
Bei diesem Test werden die Response.write-Anweisung und die Variablendeklarationen in einen Unterprogrammbereich verschoben.
<% OPTION EXPLICIT
CALL writeTable()
SUB writeTable()
Vorname abdunkeln
…
DimBirthDate
Vorname = John
…
Geburtsdatum = 1.1.1950
Response.Write(＜html＞&_
＜ Kopf ＞ & _
＜title＞Response Test＜/title＞ & _
＜ /head ＞ & _
<Körper> & _
＜ h1 ＞Antworttest＜ /h1 ＞ & _
＜ Tabelle ＞ & _
＜ tr ＞＜ td ＞＜ b ＞Vorname:＜ /b ＞＜ /td ＞＜ td ＞ & Vorname & ＜ /td ＞＜ /tr ＞ & _
…
＜ tr ＞＜ td ＞＜ b ＞Geburtsdatum:＜ /b ＞＜ /td ＞＜ td ＞ & Geburtsdatum & ＜ /td ＞＜ /tr ＞ & _
＜ /table ＞ & _
＜ /body ＞ & _
＜ /html ＞)
ENDE SUB
/app2/function2.asp-Fragment
Grundlinie = 5,57 ms/Seite
Reaktionszeit = 5,22 ms/Seite
Differenz = -0,35 ms (6,3 % Reduzierung)
Sehr interessant! Obwohl das Verschieben von Variablen in den Funktionsbereich einen zusätzlichen Funktionsaufruf hinzufügt, verbessert es tatsächlich die Leistung. Wir können die folgenden Regeln hinzufügen:
* Wenn der Code auf einer Seite mehr als einmal verwendet werden soll, schließen Sie den Code in einen Funktionsbereich ein.
* Verschieben Sie ggf. Variablendeklarationen in den Funktionsbereich.
Welche Auswirkungen hat die Verwendung von Include-Dateien?
Ein wichtiges Merkmal der ASP-Programmierung ist die Einbindung von Code von anderen Seiten. Mit dieser Funktion können Programmierer Funktionen auf mehreren Seiten gemeinsam nutzen und so die Wartung des Codes vereinfachen. Der Nachteil besteht darin, dass der Server die Seite aus mehreren Quellen zusammenstellen muss. Nachfolgend finden Sie zwei Tests mit Include-Dateien.
Binden Sie Dateien mithilfe von Inline-Code ein
In diesem Test wurde ein kleiner Codeabschnitt in eine Include-Datei verschoben:
<% OPTION EXPLICIT
Vorname abdunkeln
…
DimBirthDate
Vorname = John
…
Geburtsdatum = 1.1.1950
%>
＜ !-- #include file=inc1.asp -- ＞
/app2/include_1.asp-Fragment
Grundlinie = 5,57 ms/Seite
Reaktionszeit = 5,93 ms/Seite
Differenz = +0,36 ms (6,5 % Anstieg)
Das ist nicht überraschend. Die Nutzlast wird mithilfe von Include-Dateien gebildet.
Verwenden Sie Dateien einschließen im Funktionsbereich
Dabei wird der Code in einer Subroutine in einer Include-Datei verpackt. Der Include-Verweis befindet sich oben auf der Seite und ruft die Unterroutine an der entsprechenden Stelle im ASP-Skript auf.
<% OPTION EXPLICIT
Vorname abdunkeln
…
DimBirthDate
Vorname = John
…
Geburtsdatum = 1.1.1950
CALL writeTable()
%>
＜ !-- #include file=inc2.asp -- ＞
/app2/include_2.asp-Fragment
Grundlinie = 5,57 ms/Seite
Reaktionszeit = 6,08 ms/Seite
Differenz = +0,51 ms (9,2 % Anstieg)
Dies hat einen größeren Einfluss auf die Leistung als Funktionsaufrufe. Also: Verwenden Sie „Dateien einschließen“ nur, wenn Code von Seiten gemeinsam genutzt wird.
Wie viel Last entsteht bei der Fehlerbehandlung?
Für alle realen Anwendungen ist eine Fehlerbehandlung erforderlich. In diesem Test wird der Fehlerhandler durch Aufrufen der Funktion „On Error Resume Next“ aufgerufen.
<% OPTION EXPLICIT
Bei Fehler Weiter fortsetzen
Vorname abdunkeln
…
/app2/error_1.asp-Fragment
Grundlinie = 5,57 ms/Seite
Reaktionszeit = 5,67 ms/Seite
Differenz = 0,10 ms (1,8 % Anstieg)
Wie Sie sehen, hat die Fehlerbehandlung ihren Preis. Wir können Folgendes vorschlagen: Verwenden Sie Fehlerhandles nur, wenn etwas passiert, das Sie nicht testen oder kontrollieren können. Ein einfaches Beispiel ist die Verwendung von COM-Objekten für den Zugriff auf andere Ressourcen, beispielsweise ADO- oder FileSystem-Objekte.
Hat das Einrichten eines Kontexthandlers Auswirkungen auf die Leistung?
Wenn ein Fehler auftritt, kann das Skript durch Festlegen eines Kontexthandlers auf der Seite die Aktion rückgängig machen. Dies wird mithilfe einer Verarbeitungsanweisung auf der Seite festgelegt.
＜ %@ TRANSACTION = ERFORDERLICH % ＞
<% OPTION EXPLICIT
Vorname abdunkeln
…
/app2/transact1.asp-Fragment
Grundlinie = 5,57 ms/Seite
Reaktionszeit = 13,39 ms/Seite
Differenz = +7,82 ms (140,4 % Anstieg)
Ah! Das ist wirklich das dramatischste Ergebnis. Beachten Sie daher bitte die folgende Regel: Verwenden Sie den Verarbeitungskontext nur, wenn zwei oder mehr Vorgänge als Einheit ausgeführt werden.
abschließend
Das Wichtige am ersten Teil dieses Artikels ist die Anhäufung vieler Kleinigkeiten. Um dieses Problem hervorzuheben, habe ich einen abschließenden Test durchgeführt, bei dem ich alle Dinge durchführte, die wir zuvor getestet hatten und die harmlos schienen, aber tatsächlich eine schlechte Wirkung hatten. Ich habe eine Reihe von Response.Write-Anweisungen eingefügt, den Puffer deaktiviert, die Standardsprache festgelegt, die Option Explicit-Referenz entfernt und den Fehlerhandler initialisiert.
＜ %@ LANGUAGE=VBSCRIPT % ＞
< %
Bei Fehler Weiter fortsetzen
Vorname = John
…
Geburtsdatum = 1.1.1950
Response.Write(＜html＞)
Response.Write(＜head＞)
Response.Write(＜title＞Response Test＜/title＞)
Response.Write(＜/head＞)
Response.Write(＜body＞)
Response.Write(＜h1＞Antworttest＜/h1＞)
Response.Write(＜table＞)
Response.Write(＜ tr ＞＜ td ＞＜ b ＞Vorname:＜ /b ＞＜ /td ＞＜ td ＞ &_
Vorname & ＜ /td ＞＜ /tr ＞)
…
Response.Write(＜ tr ＞＜ td ＞＜ b ＞Birth Date:＜ /b ＞＜ /td ＞＜ td ＞ &_
Geburtsdatum & ＜ /td ＞＜ /tr ＞)
Response.Write(＜/table＞)
Response.Write(＜/body＞)
Response.Write(＜/html＞)
%>
/app2/final_1.asp-Fragment
Grundlinie = 5,57 ms/Seite
Reaktionszeit = 8,85 ms/Seite
Differenz = +3,28 ms (Anstieg um 58,9 %)
Es mag offensichtlich klingen, aber es ist wichtiger zu verstehen, dass der Code, den wir auf der Seite platzieren, einen Einfluss auf die Leistung hat. Kleine Änderungen auf der Seite können die Antwortzeiten manchmal erheblich verlängern.
Zusammenfassung der Regeln
* Vermeiden Sie den übermäßigen Einsatz von Inline-ASP.
* Verketten Sie aufeinanderfolgende Response.Write-Anweisungen immer zu einer einzigen Anweisung.
* Verwenden Sie niemals Wrapper-Funktionen rund um Response.Write, um CRLF anzuhängen.
* Wenn die HTML-Ausgabe formatiert werden muss, hängen Sie CRLF direkt in die Response.Write-Anweisung ein.
* Aktivieren Sie die Pufferung immer über die Servereinstellungen.
* Solange ASP-Anmerkungen mäßig verwendet werden, haben sie kaum oder gar keine Auswirkungen auf die Leistung.
* Stellen Sie die Standardsprachenkonfiguration des Servers so ein, dass sie mit der auf der Site verwendeten Sprache übereinstimmt.
* Legen Sie keine Sprachdeklaration fest, es sei denn, Sie verwenden eine Nicht-Standardsprache.
* Verwenden Sie in VBScript immer die explizite Option.
* Deaktivieren Sie den Sitzungsstatus immer auf Seiten- oder Anwendungsebene, wenn er nicht benötigt wird.
* Verwenden Sie „Dateien einschließen“ nur, wenn Code von Seiten gemeinsam genutzt wird.
* Wenn der Code auf einer Seite mehr als einmal verwendet werden soll, schließen Sie den Code in einen Funktionsbereich ein.
* Verschieben Sie ggf. Variablendeklarationen in den Funktionsbereich.
* Verwenden Sie Fehlerhandles nur, wenn Bedingungen auftreten, die außerhalb der Möglichkeiten des Tests oder der Kontrolle liegen.
* Verwenden Sie die Kontextverarbeitung nur, wenn zwei oder mehr Vorgänge als Einheit ausgeführt werden.
Rückblickend gibt es eine Reihe von Fragen, die als allgemeine Orientierung dienen können:
* Vermeiden Sie Redundanz – legen Sie keine Eigenschaften fest, die bereits standardmäßig festgelegt sind.
* Begrenzen Sie die Anzahl der Funktionsaufrufe.
* Reduzieren Sie den Umfang des Codes.