Warming up your web applications and websites is something which we have been doing for quite some time now and will probably be doing for the next couple of years also. This warmup is necessary to ‘spin up’ your services, like the just-in-time compiler, your database context, caches, etc.

I’ve worked in several teams where we had solved the warming up of a web application in different ways. Running smoke-tests, pinging some endpoint on a regular basis, making sure the IIS application recycle timeout is set to infinite and some more creative solutions.

Luckily you don’t need to resort to these kind of solutions anymore. There is built-in functionality inside IIS and the ASP.NET framework. Just add an applicationInitialization-element inside the system.WebServer-element in your web.config file and you are good to go! This configuration will look very similar to the following block.

<system.webServer>

  ...
	<applicationInitialization>
		<add initializationPage="/Warmup" />
  </applicationInitialization>
</system.webServer>

What this will do is invoke a call to the /Warmup-endpoint whenever the application is being deployed/spun up. Quite awesome, right? This way you don’t have to resort to those arcane solutions anymore and just use the functionality which is delivered out of the box.

The above works quite well most of the time. However, we were noticing some strange behavior while using this for our Azure App Services. The App Services weren’t ‘hot’ when a new version was deployed and swapped. This probably isn’t much of a problem if you’re only deploying your application once per day, but it does become a problem when your application is being deployed multiple times per hour.

All of a sudden all my websites didn’t work anymore. Using some common sense in searching for the root of the problem I discovered the IIS Admin Service hadn’t started after booting up my machine. Trying to manually start up the service didn’t help much either, I was confronted with a message telling me

The system cannot find the file specified.

Sadly, the event logs didn’t help much, as the logs told me about the same

The IIS Admin service terminated with the following error. The system cannot find the file specified_

Having not much to go from here I had to start searching the web to check if other people had stumbled across this issue also. Lucky for me, someone had indeed solved this problem, back in 2008 and blogged about it. Muqeet had discovered this error usually occurs when the metabase.xml file is missing or corrupt.

Checking out the default location of the metabase.xml file (C:\WINDOWS\system32\inetsrv\) confirmed this. Somehow the file was gone from the file system. Lucky for me IIS is backing up the file when a change is made within the IIS configuration. The backups can be found in the History folder (C:\WINDOWS\system32\inetsrv\History\).

Restoring the most recent backup to the original location had fixed the problem. The IIS Admin Service was able to start again, which means all the websites in IIS had started also.

It’s one of those things you need to do once and forget about it. Sometimes it’s necessary to develop something which required talking to a webservice. A lot of the times, the webservice is secured with an SSL certificate in the real world.

As most companies don’t want to spend good money to real SSL certificates for development workstations/servers, we have to create our own. You can of course develop the functionality with a non-secured environment, but for testing purposes it’s probably useful to have the test environment match the QA or production servers.

A while back I had an issue in some production software. We discovered something was malfunctioning I was needed to figure out what was wrong. As the code hadn’t changed in quite some time and it appeared the code was good (enough), I started looking at the infrastructure and discovered it might have something to do with the webservice (in SSL) it was talking to. As I couldn’t connect to the production environment, I had to connect to a local service which was running in SSL, so I did.

If you want to do this, you need to take quite some steps if you are running on IIS 6.0. This feature has improved a lot IIS 7.0/7.5. ScotGu has written a nice walkthough about this. Just hit the Create Self-Signed Certificate link and you are done. Too bad I was still developing in an IIS 6.0 environment (Windows 2003R2). I’ll describe the needed steps below.

Momenteel zit ben ik werkzaam bij een organisatie waar een ISA server als firewall dient en deze heeft een maximum ingesteld op de grootte van de Request Payload. Dit was tot voor kort geen probleem, totdat de ISA server werd geherconfigureerd.

De Request Payload is het stuk code dat de pagina van zichzelf doorstuurt naar een andere (of dezelfde) pagina. Dit is bijvoorbeeld de ViewState en alle controls en waarden binnen een form. Op een bepaalde pagina heel vaak een postback worden gedaan en iedere keer dat dit gebeurde werd de Request groter en groter. Immers, die viewstate wordt groter en alle controls met waarden worden meegestuurd.

Uiteraard wilde ik wel weten hoe groot de requests dan worden. Momenteel stond het limiet ingesteld op 5000 bytes. Dat klinkt wel als veel, maar ik heb er nooit bij stil gestaan hoe groot een request binnen ASP.NET nu eigenlijk normaal is.

Hiervoor heb ik het volgende stukje code maar in de footer van de masterpage binnen de applicatie toegevoegd:

<asp:Content
<span lang="EN-GB" style="font-family:; mso-ansi-language: en-gb;"><font style="font-size: 10pt;"><span><font color="#ff0000">ContentPlaceHolderID="PlaceHolderFooter" ID="ContentFooter" runat="server">
<asp:Literal ID="PageFooterText" runat="server" />
<asp:Literal ID="PageRequestSize" runat="server" />
<asp: Content>

En in de Page Load het volgende:

PageRequestSize.Text = string.Format("Request size: {0} bytes", Request.TotalBytes);

Nu kon ik bij het bezoeken van de pagina’s gelijk zien hoe groot de requests eigenlijk waren.

Onlangs kwamen we op het werk achter een probleem dat ons up- en download mechanisme plotseling merkwaardigheden vertoonde.
Het enige dat was gewijzigd in de afgelopen tijd was de server, een behoorlijk grote wijziging dus.
Na lang zoeken naar het probleem werd er geconstateerd dat bestanden van ongeveer 4MB wel konden worden gedownload, maar groter niet. Met deze informatie kun je lekker zoeken op internet, niet dus. Toch is er een oplossing gevonden.

De IIS-webserver werkt namelijk met een bestandje genaamd metabase.xml. In dit bestand staat de configuratie van de webserver, welke je hier ook kunt wijzigen.
Het metabase.xml bestand staat in de system32-map van de server, bijvoorbeeld C:\WINDOWS\system32\inetsrv\\metabase.xml

Om de download limiet te verhogen zoek je het element AspBufferingLimit op. Standaard staat deze ingesteld op AspBufferingLimit="4194304" (bij ons tenminste). Dit getal kun je verhogen (of verlagen) naar het aantal bytes dat je graag als maximum wilt opgeven.

Ok, dit is waarschijnlijk niet nodig als je gewoon een bestand uit een map wilt downloaden, maar wel als je een binair bestand uit een database wilt downloaden. Dan heb je een iets grotere buffer nodig als 4MB.
Diezelfde week had ik een probleem met het uploaden van bestanden met een uploadmodule bij een klant. Hier konden niet bestanden worden geupload die groter waren als 200KB. Nu kun je zeggen dat de klant dan maar FTP moet gaan gebruiken, aangezien HTTP niet voor bestanden uploaden is bedoeld, maar daar zit die natuurlijk ook niet op te wachten.