Direkt zum Hauptbereich

ASP.NET-Applikationen: warum debug="false"?

Warum ist folgende Aussage ernst zu nehmen?

Stellen Sie sicher, dass debug="false" im compile-Element der web.config-Datei für jede ASP.NET-Applikation auf dem Produktionsserver gesetzt ist. Während der Entwicklungsphase ist der Standardwert "true", was häufig dazu führt, dass diese Einstellung auch im Echtbetrieb beibehalten wird. Dieser Umstand kann führt zu ineffizientem Speicherverhalten.

Welche Probleme verursacht debug="true"?

Es gibt drei Unterschiede zwischen debug="true"/"false":
  • ASP.NET-Timeouts
  • Batch-Kompilierung
  • Code-Optimierung

1. ASP.NET Timeouts

Wenn debug auf "true" gesetzt wird, erhalten ASP.NET-Request keinen Timeout. Damit soll gewährleistet werden, dass Entwickler in Visual Studio in Ruhe ihre Applikation testen und debuggen könnnen, ohne ständig mit Timeouts konfrontiert zu werden. Natürlich sind Timeouts im Echtbetrieb ein unerlässliches Mittel, damit Anfragen nicht ewig hängenbleiben und Systemressourcen blockieren.

2. Batch-Kompilierung

Kurz gesagt, wenn debug="true" kann eine Batch-Kompilierung erfolgen, sonst nicht. Was bedeutet das?

Wenn eine aspx-, asax- oder ascx-Datei zum ersten Mail aufgerufen und in eine Assembly kompiliert wird, erhält sie einen in acht Zeichen kodierten Namen (z.B. 2nt0rgwd.dll or ähnlich). Diese temporäre Assembly wird für jede Datei der genannten Typen im Verzeichnis "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files" + Applikationsname. Die Klasse, die aus dem "Code-Behind" resultiert, wird mit allen anderen DLLs aus dem bin-Verzeichnis als Schattenkopie in diesem temporären Verzeichnis abgelegt.
Zurück zur 2nt0rgwd.dll. Wenn debug="true", dann wird pro aspx, asax und ascx eine einzelne Datei erzeugt. Das heißt zum Beispiel, für 100 Dateien werden 100 DLLs erzeugt, und das zum Zeitpunkt, wenn die Seite oder das Control das erste Mal aufgerufen wird.
Wenn hingegen debug="false" gesetzt ist, erfolgt die Kompilierung als Batch, das heißt, das beim ersten Aufruf irgendeiner Seite in der Applikation die Gesamtheit aller Seiten und Controls in eine große DLL kompiliert wird. Diese Aussage ist noch ein wenig zu relativieren, denn ascx werden in eine getrennte Datei kompiliert und die aspx werden in Gruppen mit den Usercontrols, die sie inkludieren, kompiliert. Auch die global.asax-Datei wird in eine eigene Datei kompiliert. Außerdem geschieht die Kompilierung noch auf Verzeichnisebene, d.h. Unterverzeichnisse erhalten auch eigene Dateien. Aber im Großen und Ganzen ist die Anzahl anstatt 100 doch nur vielleicht 3 oder 4.
Was ist nun der Nachteil, wenn es viele DLLs sprich Assemblies gibt? Der Adressraum im Speicher wird wesentlich ungünstiger verwendet, sprich fragmentiert. Dieser Umstand bewirkt, dass es für die Laufzeitverwaltung von .NET schwieriger wird, geeignet große Blöcke auf dem Heap zu finden. Somit wird der Overhead und Speicherbedarf unnötig erhöht.
Etwas ist noch zu beachten. Wenn eine einzige aspx-Datei geändert wird, wird diese Datei extra kompiliert, damit nicht die gesamte App-Domain neu geladen werden muss. In der machine.config gibt es diesbezüglich eine Einstellung, in der festgehalten ist, wie viele derartige Änderungen maximal gemacht werden können, bis die App-Domain neu geladen wird, gerade so, als ob die web.config oder das bin-Verzeichnis geändert wurden.

3. Code-Optimierung

Damit man in der Entwicklungsphase fähig ist, Schritt für Schritt durch den Code zu gehen, ist in dieser Phase der JIT-Compilter (Just in Time) ausgeschalten. Die Code-Optimierung erfolgt also nur, wenn der Debug-Schalter auf "false" gesetzt ist.
Insgesamt also genügend Gründe, um diese wichtige Einstellung auf den Produktionssystemen richtig zu stellen.

Übrigens: In einem Speicherabbild (Memory Dump) kann identifiziert werden, ob die Applikation im Debug-Modus lief oder nicht. Das Kommando !finddebugtrue in der sos.dll listet alle Applikationen mit debug="true" in the web.config auf. Einfach, nicht?

In ASP.NET 2.0 gibt es einen Schalter in der machine.config, der alle debug="true" deaktiviert, so dass auf einem Produktionsserver alle Applikationen automatisch mit debug="false" laufen:


<configuration>
   <system.web>
      <deployment retail="true"/>
   </system.web>
</configuration>


Weitere Goodies zum Thema im Blogeintrag von Scott Guthrie.

Kommentare

Beliebte Posts aus diesem Blog

Befehle der Eingabeaufforderung

Wer kann sie alle aufzählen. Auswendig bestimmt nicht. 95% davon habe ich wohl noch nie im Leben verwendet:ASSOC
Zeigt Dateierweiterungszuordnungen an bzw. ändert sie.AT
Legt eine Zeit fest, zu der Befehle und Programme auf diesem Computer ausgeführt werden. ATTRIB
Zeigt Dateiattribute an bzw. ändert sie. BREAK
Schaltet die erweiterte Überprüfung für STRG+C ein bzw. aus. CACLS
Zeigt Datei-ACLs (Access Control List) an bzw. ändert sie. CALL
Ruft eine Batchdatei aus einer anderen Batchdatei heraus auf. CD
Zeigt den Namen des aktuellen Verzeichnisses an bzw. ändert diesen. CHCP
Zeigt die aktive Codepagenummer an bzw. legt diese fest. CHDIR
Zeigt den Namen des aktuellen Verzeichnisses an bzw. ändert diesen. CHKDSK
überprüft einen Datenträger und zeigt einen Statusbericht an. CHKNTFS
Zeigt die Überprüfung des Datenträgers beim Start an bzw. verändert sie. CLS
Löscht den Bildschirminhalt. CMD
Startet eine neue Instanz des Windows-Befehlsinterpreters. COLOR
Legt die Hintergrund- und Vordergrundfarben für …

Serverseitige Kommentare in ASP.NET

Wer einen Code-Block in der HTML/XML-Ansicht in aspx-Seiten oder ascx-Controls kommentieren möchte, kann dies mit folgenden Zeichenfolgen machen:

<%--
Auskommentiertes HTML/CODE/Markup.
Alles innerhalb dieses Blockes wird von ASP.NET nicht geparst oder kompiliert.
<%# Eval(“SomeProperty”) %>
--%>

Sehr hilfreich, wenn man das weiß und anwenden kann. Normale HTML-Kommentarzeichen haben den großen Nachteil, im Quellcode des Browsers aufzuscheinen.

SSL/https erzwingen mit IIS (Windows Server 2003)

Kürzlich musste ich eine Webapplikation rein über SSL (https, Port 443) zugänglich machen und eine automatische Weiterleitung an die sichere Adresse einstellen. Ich fragte mich, wie ich das machen könnte, ohne zwei virtuelle Websites zu erstellen.Ich habe das auf folgende Weise bewerkstelligt. Unter Eigenschaften der Website im Reiter "Verzeichnissicherheit" im letzten Abschnitt "Sichere Kommunikation" den Bearbeiten-Knopf drücken und dort einstellen, dass SSL erforderlich ist (erste Checkbox). Achtung: Das bewirkt, dass alle http-(Port 80)-Anfragen einen HTTP-Fehler im Browser bewirken und zwar den Fehler mit dem Code 403;4 ("Forbidden SSL required"). Diesen Umstand kann man nun ausnützen, indem man eine benutzerdefinierte Fehlermeldung einstellt.Dazu erstellen wir zuerst ein simples asp-Script<%@ Language=VBScript %>
<%
If Request.ServerVariables("SERVER_PORT")=80 Then
   Dim strSecureURL
   strSecureURL = "https://"
   strSecure…