Scott Hanselman

Penny Pinching in the Cloud: Your web app doesn't need 64-bit

October 6, '15 Comments [21] Posted in Azure
Sponsored By

Often times I hear folks say that they need (or want) 64-bit support when they deploy to the cloud. They'll deploy their modest application to Azure, for example, as a Web Application, then immediately go to the settings and set it to 64-bit. So many years later and it's "do I need 64-bit" is still confusing to a lot of people.

Change your Azure bitness settings here

I made basic Hello World ASP.NET app and deployed it. Now, I go to that Web Apps "blade" in the Azure Portal, click Tools, then Process Explorer (after exercising the app a little.) I'm running 32-bit here. The K is the Kudu "sidecar" deployment site (for things like Git deploy and diagnostics), and the other icon is the production site.

30 meg working set for IIS in 32 bit mode

Now, I'll swap it to 64-bit and exercise the web app again. Remember, this app is just a super basic app.

102 meg working set in IIS in 64-bit mode

See how the working set (memory) jump? It's a little extreme in a hello world example, but it's always going to be bigger than 32-bit. Always. 64-bit'll do that. Does your site need to address more than 4 gigabytes of memory from any single process? No? Then your web app probably doesn't need to be 64-bit. Don't believe me? Test it for yourself.

I'll go even further. Most web apps don't need 64-bit, but here's the real reason. If you stay 32-bit when putting your Web Application in the cloud you can fit more applications into a limited space. Maybe your Medium App Service Plan can actually be a Small and save you money.

Until 64-bit only is the default in things like Nano Server, today you can fit more Web Apps into limited memory if you stick with 32-bit.

I personally have 18 web apps in a Standard Small App Service in my personal Microsoft Azure account. They are sites like my podcast Hanselminutes and they get decent traffic. But most never get over 300-600 megs of memory and there's literally no reason for them to be 64-bit today. As such, I can fit more in the Small App Service Plan I've chosen.

18 web apps in a single app service plan

Remember that the Azure Pricing Calculator isn't totally obvious when it comes to Web Applications. It's not ~$55 per Basic Web Site. There's a Virtual Machine under there, they call the whole thing an "App Service Plan" and your Web Apps sit on top of that plan/VM. It's really $55 for a plan that supports as many web applications you can comfortably fit in there.

The cloud is a great deal when you're smart about the resources you've been given. If you're using Azure and you're not using most of the the resources in your service plan, you're possibly wasting money.

What Penny Pinching in the Cloud tips do you have? Disagree with this advice? Sound off in the comments.

Related Links


Sponsor: Thanks to my friends at Accusoft for sponsoring the feed this week. Just a few lines of code lets you add HTML5 document viewing, redaction, annotation, and more to your apps and websites. Download a free trial now!

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb
Tuesday, 06 October 2015 07:04:49 UTC
Is it really 4Gig ? I've seen 32bit process with something like 1.7Go throwing outofmemory, the os, and the clr keep a lot of memory for themselves in a process.
Bourgarel Remi
Tuesday, 06 October 2015 07:31:46 UTC
Thanks for the great tip Scott.
I have a 64-bit server, should I have my MVC web app as 32-bit or 64-bit on it?
Or shall I switch to a 32-bit server and have a 32-bit web app on it.
Please advise.
Thanks
Manish
Tuesday, 06 October 2015 07:52:41 UTC
Manish,

64 bit server, 32 bit app.
Henri Toivonen
Tuesday, 06 October 2015 08:49:25 UTC
Bourgarel,

The 4gb is split into 2 sections. 2gb of it is for the app and the remaining 2gb is something to do with the OS. I can't remember the specifics but that's why your app will crash if you hit the 2gb limit
Matthew Steeples
Tuesday, 06 October 2015 08:58:00 UTC
So we can host multiple web apps in one single application service. But if all these web apps need sql database I will still need separate SQL Database plans for each of the web apps right?

Assuming I have 5 web apps that needs S0 database plan, my cost for the sql database will be 5 x USD15 = USD75 monthly for the database alone, am I right?

That is why I stick to Azure VM + Sql Express. Sure I lose all the pros of a web app but that is all I can afford.
Rosdi
Tuesday, 06 October 2015 09:26:51 UTC
I have the same question Rosdi. It's worse if they use DocumentDB at ~$30 per month each.
Tuesday, 06 October 2015 12:07:26 UTC
In the Enterprise world, choosing 64-bit now means you may be able to move to 64-bit in the future, even if you don't use it now.

If you choose 32-bit, you'll need to file multiple change requests for the infrastructure with an entire years-long project devoted to analysis of the 'migration.'

Then you'll need to find a way to convince management that there's a benefit to 64-bit that justifies the time spent migrating your application.

They're convinced? Great! Now the item is at the VERY bottom of your backlog, and will never leave there as long as product management has a single feature they want in the app.


If you choose 64-bit now, however, all you have to do is convince management that you can make better use of the existing resource with application changes. You're "saving money."
Anon
Tuesday, 06 October 2015 12:55:39 UTC
It ends up being the Kudu stuff that pushes me over the edge. I wish mine was under 40 MB per site! It's not unusual to see it over 100 MB for me.
Tuesday, 06 October 2015 15:17:07 UTC
It could also crash before 2GB if you don't have enough contiguous memory. http://blogs.msdn.com/b/ericlippert/archive/2009/06/08/out-of-memory-does-not-refer-to-physical-memory.aspx
Josh
Tuesday, 06 October 2015 16:08:54 UTC
What about using 64-bit integers, for example as database keys if you have a huge number of entities in your database? Sure, you could use GUIDs or whatever as well, but that would use even more memory. Or if you need 64-bit arithmetic. Probably won't make a huge difference anyway, but I mean it's not just the RAM.
Tuesday, 06 October 2015 18:38:25 UTC
@riipah - Int64 will work on 32-bit it's just infinitesimally slower. CPUs are so fast these days that you will be unable to measure that difference.
PRMan
Tuesday, 06 October 2015 20:10:46 UTC
This is always funny, since even devs to some level still don't fully understand 64 bit. But suffice to say, 64 bit is not just the memory.
The most important one that people always forget about is security. If an application of any size uses HE ASLR then it helps mitigate attacks, regular ASLR can also help too, but it can be more predictable.
Why does this help with security, and why is this good for a web app? Well, for security, ASLR moves things around in memory, so you can't easily guess where things are but 64 bit processes are able to move things around further. This helps mitigate certain attacks because filling up 8TB/128TB of address space is much easier than filling 2 to 4GB (remember, WoW64 processes on 64 bit windows and the userva option for 32 bit windows allows applications access to more of the process' address space). Why this is always good for a web app is that it is a web facing application, so security should always be high priority.
But this is a similar reason why there has been a trend towards 64 bit web browsers even though 32 bit browsers still seemingly suffice.

There are other things that could also mean that 64 bit programs are better off than 32 bit. But I personally think the importance of these are lower due to them just being potential performance increase sources. (And yes, if the compiler/JIT compiler does it right, they can offset the problem of cache misses and them more.)
Darran
Tuesday, 06 October 2015 21:09:20 UTC
Penny pinchers?

AWS auto scaling termination policy of ClosestToNextInstanceHour.

Or if using scheduled actions, time the scale downs to happen after x hours & 55 minutes (adjust for connection draining as needed).
Peter Mounce
Thursday, 08 October 2015 17:37:33 UTC
@Bourgarel Remi: It is surprising that no one knows the answer. If you are running on 32 bit Windows you get only 2 GB of your address space. If you are running on 64 Bit Windows then you will get the full 4 GB of address space if and only if your application has set the ( Large Address Aware flag set in the PE Header).

For Azure powered machines which are all running 64 bit versions of Windows (I suppose) you get the full 4 GB of address space. .NET applications had not always set this flag but current executables produced by the C# compiler have it set. You can check it with DumpBin /headers xxxx.exe where you should see the line:

Application can handle large (>2GB) addresses.

Monday, 12 October 2015 07:24:22 UTC
@Henri Toivonen
Thanks for the advice.
Monday, 12 October 2015 20:34:57 UTC
I see you have .net Framework 4.6. I've been working with Worker Roles and I had to manually add a script to install that framework on my hosted VM. Why is it the Azure Services do not have 4.6 supported yet?
Tuesday, 13 October 2015 14:58:28 UTC
@Rosdi, using VMs is always a bad bad choice for web apps. Use App Service Plan and deploy your app to it, then you get 99.95% SLA. With a VM you need two instances running to get 99.95% SLA.

For databases, why not just use 1 S0 database and have schemas for each "database". That way they won't touch each other and you can scale it as you like. Better yet, set up a Database Pool and stick all the DBs you need in there and share the IOPS (DTUs) across them as you can afford. With SQL database (in contrast to SQL Express on a single-point-of-failure no SLA VM) you get 99,99% SLA and 14 days backup (point-in-time-restore) and much more.
HansOlavS
Monday, 19 October 2015 09:05:21 UTC
@HansOlavS,

Not having a small database for free in Azure is a bummer. For example I now want to play/experiment/prototype a website on my own. So it is nice I can start by using the free App Service. But almost every website needs a database. So you hit a brick wall soon if you don't want to pay real money. I'm just saying I don't need much I just need a little bit, just something to get started. I doesn't have to be fast. Maybe a option to just stop a database and only pay for running hours.
Bas Jansen
Wednesday, 21 October 2015 05:56:12 UTC
@HansOlavS, Now why didn't I think of that!... I could have used different schema for each "database"... I guess that could work.. I will experiment on it.. thanks for the idea!

Yes I understand the pros and cons of using VM instead of Azure App/Database Service.. I am just trying to keep my cost affordable since I have about 10 different websites and subscribing to 10 Azure database plans is too costly for me.

The idea of separating them according to schemas could work.. but I will have to try it first especially on the access control. Each schema should have different access credential, none of the application can access other schemas.
Rosdi
Wednesday, 21 October 2015 06:02:51 UTC
@Bas Jansen, you could use Sql Server Compact if that fits your needs. Read more here: http://www.dotnetcurry.com/windows-azure/883/host-aspnet-mvc-azure-without-database
Rosdi
Wednesday, 21 October 2015 11:13:06 UTC
@Rosdi,

Thanks for the tip! I tried with sqlite (compact is not yet supported by the Entity Framework 7) but in the free app service I run out of disk space. I did some checking and it looks like the local temp disk is too small since adding the sqlite dependencies. The answer could be "just upgrade to Basic" but 47,- euros a month hurts just to experiment.
Bas Jansen
Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.