5
Vote

Investigate app startup time on low spec servers (Azure X-Small, Gearhost CS)

description

Bertrand requested we file a bug to track this. The app startup time for my barebones Orchard blog on an Azure extra small instance is ~4.5 minutes (gbiamby.cloudapp.net, not guaranteed to be there by the time someone looks at this ticket).

Repro steps:
  1. Check out changeset: bc14927cf18790f91d6ecc42cef8dd8727705a41
  2. Apply patch from work item 19119 (to fix MVC4 errors when you try to run the site on Azure)
  3. Build using ClickToBuildAzurePackage.cmd
  4. Deploy to Azure.
  5. Visit website. Initial visit, and any visits after a period of no activity result in a ~4.5 minute wait time before you get an HTTP response. Subsequent page hits load at a normal speed.
More info: http://orchard.codeplex.com/discussions/274921#post925349

I left this line in my ServiceConfiguration.csfg, could this be part of the problem?
<Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="UseDevelopmentStorage=true" />
I'm not sure if I'm supposed to set up another db or use the same connection string as for "DataConnectionString".

comments

sebastienros wrote Oct 11, 2012 at 7:35 PM

First, create a db for sure. Don't use SqlCe and don't use DevelopmentStorage.

TheMonarch wrote Oct 11, 2012 at 9:26 PM

Startup time is now 28s. To be clear, i was using SQL Database for the orchard, but i left the Diagnostics connection string as developmentStorage.

I'll check the start-up time again over the next couple of days to make 28s wasn't a fluke.

The other guys in the thread I linked to still had trouble with 50s start-up times on their hosting. May still want to look into those.

TheMonarch wrote Oct 11, 2012 at 9:27 PM

Note: startup went down to 28s after I edited the diagnostics connection string to match the DataConnectionString.

BertrandLeRoy wrote Oct 11, 2012 at 10:53 PM

That's still too much. Did you check you were running release-compiled bits, with shape tracing off?

TheMonarch wrote Oct 12, 2012 at 12:26 AM

Start-up time is still 28s. Deployed again, this time with 1.x tip, which includes the update to disable appPool timeout. First page hit after starting the instance up is still 28s, subsequent page loads are 200-400ms (good).

Verified that the assemblies are compiled in RELEASE mode, and are OPTIMIZED (used Assembly Information to inspect the build output).

Are you sure this isn't just Azure Extra Small instance being slow? Is there some kind of diagnostic info I can provide from the Azure web role that would help?

TheMonarch wrote Oct 12, 2012 at 12:29 AM

Shape tracing is off. Everything is default as per blog recipe.

gregslater wrote Jan 29 at 1:48 PM

For an extra small instance 28 seconds sounds about the same as I've experienced for the initial startup time. I've also experienced the 4 minute wait with UseDevelopmentStorage=True.

Make sure that debug="false" is set on the compilation tag in the Orchard.Azure.Web web.config file. This will give you a small improvement.

Also, make sure you've disabled both app pool timeout and regular recycle by running these commands in an elevated prompt on startup:

%windir%\system32\inetsrv\appcmd set config -section:applicationPools
-applicationPoolDefaults.recycling.periodicRestart.time:00:00:00

%windir%\system32\inetsrv\appcmd set config -section:applicationPools
-applicationPoolDefaults.processModel.idleTimeout:00:00:00

Sign in to add a comment or to set email notifications