Startet man eine ASP.NET Anwendung zum ersten Mal, kommt man nicht gerade in einen Geschwindigkeitsrausch. Dies liegt zum Beispiel daran, dass der IIS den ASP.NET Worker Prozess hochfahren muss. Außerdem läuft eventuell im Ereignis Application_Start hinterlegter Initialisierungscode und schließlich müssen die vorliegenden Assemblies noch durch den JITer in nativen Code überführt werden.

All dies führt dazu, dass man relativ selten so etwas wie "rasend schnell" hört, wenn vom ersten Zugriff auf eine ASP.NET Anwendung gesprochen wird.

Glücklicherweise ist all dies nach dem ersten Request einer Seite kein Problem mehr. Der Worker Prozess ist da, der Initialisierungscode lief und die Just In Time Compilation lief auch.

Zu einem Problem wird die Situation jedoch, wenn man seine ASP.NET Anwendung während der Entwicklung als ein Bestandteil des Nightly Builds automatisch deployed und auch seinem Kunden Zugriff auf diesen täglich frischen Applikationsstand gibt.

Da Kunden morgens nämlich meist früher als Entwickler im Büro sind, sind sie auch die ersten, die die Webanwendung öffnen, um zu sehen, was am Vortrag umgesetzt wurde. Ist dieser erste Zugriff nun aus den oben genannten Gründen langsam, ist negatives Feedback des Kundens zur Applikationsperformance - oder sogar noch schlimmer: im Stillen sinkendes vertrauen in Applikation und Entwickler nicht selten die Folge.

Um dieses Problem zu umgehen, habe ich ein kleines Powershell Script geschrieben, das nach Angabe einer URL die einzelnen Seiten einer Webapplikation ansurft. 

function warmup-site( [string] $rootUrl){
	
	$proxy = New-Object System.Net.WebProxy("mein.firmen.proxy:8080")
	$proxy.UseDefaultCredentials = 1
	
	$wc = New-Object System.Net.WebClient
	$wc.Proxy = $proxy
	
	$pages = @("default.aspx", "seite1.aspx", "seite2.aspx", "subfolder/seite3.aspx")

	# Jede Seite 3 Mal ansurfen, um Sie "warmzuklicken"
	for ($i=0; $i -lt 3; $i++){
		foreach($page in $pages){
			trap [System.Net.WebException] {
			  write-error $("TRAPPED: " + $_.Exception.ToString());
			  continue;
		   	}
			$content = $wc.DownloadString($rootUrl+$page)
			write $("URL " + $rootUrl+$page + " angesurft");
		}
	}

}

warmup-site("http://meine.url/")

Bisher gebe ich die einzelnen Seiten die angefragt werden sollen noch manuell innerhalb des Arrays $pages an. Im nächsten Schritt würde ich jedoch lieber nur noch die URL der Sitemap angeben, diese auslesen und dann sämtliche in der Sitemap aufgeführten URLs anfragen. Da ich jedoch noch Powershell Neuling bin, könnte es noch ein wenig dauern, bis ich die Lösung so weit automatisiert habe. Sollte einer der Leser nun sagen: "Das ist doch ein Dreizeiler, den ich in der Kaffeepause aus dem Ärmel schütteln könnte", dann würde ich darum bitten genau diesen Dreizeiler über die Kommentarfunktion meines Blogs hier einzustellen

Was bringts?

Die Anwendung startet beim ersten Request nun bedeutend schneller. Somit ist der Kunde beruhigt und wir können uns auf die wichtigen Sachen des Projekts konzentrieren

Habe übrigens gesehen, dass es ab dem IIS 7 (oder 7.5?) von Hause aus eine Warmup gibt. Hat jemand von euch Erfahrung damit? Im Moment ist es für mich zwar noch nicht akut, da wir den IIS 6 nutzen, wäre aber Interessant für die Zukunft ein paar Erfahrungsberichte zur Hand zu haben.

Vor einiger Zeit habe ich ein kleines Einsteigertutorial zum Umgang mit WinDbg geschrieben. Etwas später folgte dann auch ein kurzes Video hierzu.

Sowohl im Tutorial als auch im Video war eine Windows Forms Anwendung das Ziel meiner Debuggingaktivitäten. In einem kurzen Nebensatz erwähnte ich, dass die Zielanwendung bei der gezeigten Vorgehensweise, nämlich dem direkten Anhängen an den Prozess der Wahl, zumindest zeitweise blockiert wird.

In einer Windows Forms Anwendung mag dies kein Problem sein, schließlich bin ich ja alleine auf dem System. Unschön wird es jedoch, wenn man Probleme in einer produktiven ASP.NET Anwendung sucht. Verständlicherweise reagieren hier nämlich die wenigsten Anwender erfreut, wenn die Website steht weil gerade jemand im Hintergrund daran herumfummelt. Außerdem ist es je nach IT Richtlinie auch problematisch den lokalen Administrator des Kundens davon zu überzeugen, dass man mal gerade physikalisch oder auch nur per Remote Desktop an seinen Webserver will.

Und nun?

Abhilfe schafft hier die VBScript Datei adplus.vbs innerhalb des WinDbg Verzeichnisses. Sie ermöglicht es, ein aktuelles Speicherabbild des problematischen Prozesses in Form einer *.DMP Datei zu erstellen. Diese kann wiederum in WinDbg geöffnet und analysiert werden.

Adplus kann in zwei verschiedenen Modi genutzt werden: hang und crash.

Im hang Modus wird einmalig ein aktueller Memory Dump des Prozesses zum Zeitpunkt der Ausführung des Scripts gezogen. Dieser Modus eignet sich besonders wenn die Applikation "hängt" , also in Deadlock Szenarien, oder aber auch um Memory Leaks zu finden. Zur besseren Analyse sollten im Fall ein Memory Leaks jedoch mehrere Dumps bei verschieden hoher Speicherauslastung gezogen werden.

Der Befehl zum Erzeugen eines Dumps im hang Modus lautet übrigens:

adplus.vbs -hang -p processId

Die Id des Prozesses kann entweder über den Taskmanager, oder aber im Fall einer ASP.NET Anwendung die in einem IIS 6 gehostet wird, über den Befehl IISAPP gefunden werden.

Alternativ zum Parameter -p kann über den Parameter -pn auch ein Prozessname angegeben werden. Im Fall einer ASP.NET Anwendung wäre dies also W3WP.exe (Windows Server mit IIS) bzw. WebDev.WebServer.exe im Falle des lokalen Entwicklungsservers. Außerdem kann über den optionalen Parameter -o auch ein dediziertes Ausgabeverzeichnis angegeben werden. Standardmäßig wird nämlich sonst ein Unterverzeichnis, unterhalb des Ordners aus dem adplus heraus aufgerufen wurde, angelegt.

Innerhalb des Zielverzeichnisses wird nun eine Datei mit der Endung .DMP angelegt. Diese kann in WinDbg über den Menüpunkt File -> Open Crash Dump ... geöffnet und mit den bereits bekannten Befehlen analysiert werden.

Der zweite Modus neben hang ist der Modus crash.

Der Aufruf erfolgt hier ähnlich zum hand Modus, mit dem einzigen Unterschied, dass statt -hang -crash übergeben wird.

adplus.vbs -crash -p processId

Im Crash Modus bleibt der Debugger so lange am entsprechenden Prozess angehangen, bis dieser unfreiwillig beendet wird. Tritt dieser Fall ein, wird ein Dump auf die Festplatte geschrieben. Außerdem werden Dumps geschrieben, wenn ein zuvor definierter Breakpoint erreicht wird, oder aber eine access violation Exception auftritt.

Fazit

Mit adplus liegt ein leichtgewichtiges Skript zur Hand, dass bei der Problemanalyse innerhalb produktiver Umgebungen enorm helfen kann. Gerade in Umgebungen, in denen das Live-System nicht durch Debugging blockiert werden darf, oder aber der Administrator keinen Zugriff auf das System gewährt, kann das Skript seine stärken Ausspielen.

One of the many benifits as an Infragistics MVP is that you get quite early involved in product development in order to give feedback.

This could either be feedback on a new feature, an API change, or a brand new product!

Last spring it was time to give feedback again. There was an email on the Infragistics NDA mailing list which announced that work on a new product - Infragistics NetAdvantage for Powershell - had been started. Being an absolute Powershell fan, I felt really excited to offer my help with alpha and beta testing, giving feedback, etc.

After some great discussions between the director of product management Joseph Berres, lead developer Ambrose J. Tall and some Infragistis MVPs, the team managed to finish a first proof of concept prototype in early September. Some weeks later I met Dr. Tony Komischke, Director of User Experience at Infragistics, at the Basta conference in Germany. There he gave me a first demo of the product. At this point he was able to show me an early Version of the powershell grid: Infragistics NetAdvantage for Powershell powerGrid. I would have loved to see the charting component powerChart, too. Unfortunately it hadn't been ready for presentation at that time.

To my question how the idea for a whole powershell suite had been born, Tony Komischke gave me a quite interesting answer:

It was actually one of our internal IT guys who had the idea. During a meeting he complained that lately more and more server products came to market without an usable admin UI. Instead he had to struggle with some colourless command line tools.

This situation started the whole thing. We all thought that Windows administrators love decent UIs and don't want to work with a boring command line. If they liked the command line, they would have become Linux administrators!

And that's the point of Infragistics NetAdvantage for Powershell. With this product, we give administrators back what they deserve!

Since Basta conference some time went by. The product has nearly arrived at its final state. Starting with tomorrow, registered users will be able to download at CTP Version of it in the download area of Infrastics' homepage.

The first webinars on NetAdvantage for Powershell will be made available approximately next week by Infragistics new media evangelist Jeff Shoemaker.

During the quaterly Infragistics MVP call, Mr Beres stated:

"We really wanted to show off our high end visualizations in a DOS window" said Beres.  "PowerShell gave us a great opportunity to mix data analytics with the new features in the Command Window, like colorization" he continued.

As an Infragistics MVP I already enjoyed testing the product. Below you're going to find some impressions:

The powershell standard output

Output as PowerGrid. Notice the usage of the sortable table pattern as well as table and column borders.

The corner treatements pattern which includes curves in all rectangle corners didn't make it into the CTP as there were some performance issues with GDI+ and the gpu's hardware acceleration.

Output as PowerChart. I've chosen a bar chart as output type