Penny Pinching in the Cloud: Your web app doesn't need 64-bit
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.
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.
Now, I'll swap it to 64-bit and exercise the web app again. Remember, this app is just a super basic app.
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.
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
- Penny Pinching in the Cloud: Enabling New Relic Performance Monitoring on Windows Azure Websites
- Penny Pinching Video: Moving my Website's Images to the Azure CDN (and using a custom domain)
- Penny Pinching Video: Moving an Azure Website between data centers
- Pinching pennies when scaling in The Cloud - lazy loading images and using the Azure CDN to save money
- Penny Pinching in the Cloud: How to run a two day Virtual Conference for $10
- Penny Pinching in the Cloud: When do Azure Websites make sense?
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.
About Newsletter
Bourgarel Remi
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
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
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.
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."
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.)
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).
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.
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.
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.
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.
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.
Comments are closed.