Reducing delay after deployment to IIS

Legacy Uncategorised
1

Hi,

I noticed in other threads you talked about aspnet_compiler.exe to help reduce the refresh time between deployments (the annoying delay where IIS does stuff after file changes).

I’ve got this process:

Jenkins -> Executes psake build script which includes:
Compile ASP.NET MVC site
Package ASP.NET MVC site (does web.config transforms, essentially the VS Publish command)
Call aspnet_compiler.exe on package directory
Call aspnet_merge.exe on package directory
Call nuget.exe to make a nuget package

I do this but still I get the IIS 3-4 second delay with a simple test asp.net mvc site and I know it will be much worse on my larger, live project I want to use Octopus with.

Any hints or have I misunderstood your hints (I’m thinking you meant call aspnet_compiler AFTER the files are deployed? Like in a Deploy.ps1 script and doing it to the NuGet package won’t do the same?

I could look at doing the web farm route, but this is one server, will stay one server for a few more years.

In summary, I’m really hating IIS for deploying files :frowning:

2

Hi Phil,

Sorry for the delayed reply on this.

I suspect the delay you are talking about is relating to:

  1. Starting up the application pool
  2. NGening the code
  3. Running global.asax and initializing other ‘startup’ stuff

To warm this up, you could try a PostDeploy.ps1 that makes an HTTP request (using the WebClient object) to the site. This will force the full ASP.NET pipeline to run as soon as possible.

Hope that helps,

Paul

3

Hi Paul,

Hmm this isn’t really an octopus problem, just that deployment to a site running on a single server using IIS sucks :frowning:

Is there a way to blue green deployment using Octopus?

E.g.

Use Powershell to figure out which of two IIS sites is inactive.

Deploy to that IIS site.

Swap up inactive site (via port binding).

Swap bindings from active to inactive.

The only problem I can see with this approach is telling Octopus which site to do the deploy to, I’m not sure you can do this.

I’ve been working on a Powershell script to do this, although I’m noticing if you ping it whilst Powershell swaps bindings, you get ~1000ms of responses waiting.

Still trying to get to the elusive, CI + CD environment where I can push a new version to a single server and have no downtime/lost data when the new version is swapped in.

Thanks,

Phil

4

Hi Phil,

You could do all of that by using PowerShell, and then telling Octopus not to change the site settings (there’s a variable for that), and handling it yourself via PowerShell. That would definitely work. How does that sound?

However, I think you might still experience some warm-up when you change the bindings - but I haven’t tested this.

Paul

5

Hi Paul,

Yes, I have a PS script that does blue green deployment, nearly finished it when I got an email about Octopus release :slight_smile:

The only problem I see is with blue green deployment, you have two IIS sites and deploy to the inactive. Can you tell Octopus which site to deploy to via PS?

Thanks,

Phil

6

Hi Phil,

Good question. Octopus doesn’t exactly deploy to a ‘site’. It deploys to a machine, and if a web site exists following a convention, it updates the site. But that last part can be disabled.

So Octopus would deploy the package to the machine, and then your script would do the blue-green deployment (selecting the right site, re-configuring it, and so on). Octopus wouldn’t touch IIS - its job would just be to extract the package and invoke the powershell script.

I hope that makes sense?

Paul

7

Hi Paul,

Perfect sense. Sounds like a plan :slight_smile:

Thanks,

Phil

Sent from my Windows Phone

From: Paul Stovell
Sent: 02/07/2012 16:30
To: Phil Jones
Subject: Re: Reducing delay after deployment to IIS [Questions]

8

Great. The variable you’ll need to set is:

OctopusNotAWebSite = True

That tells Octopus not to modify your IIS settings.

Paul