Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Azure Web Sites Sucked in Production

elekslabs.com

Post reply on HN
Print view View original

21–30 of 48 posts

Re: How Azure Web Sites Sucked in Production

#21

Post by marcosdumay »

callumjones wrote: post #14

Here's the take-away from this post * You treated the system's memory like it was some infinite resource. It's not, you need to make sure your application efficiently handles memory and takes measure to ensure it doesn't grow too large. Would you want it swapping on a regular host? * You thought you could get away with a free database that is used for development. You're using an application that isn't built well for…

Take-aways that must came with yours:

* There is no way to calculate memory usage, it's completely opaque. The first thing the author told was how he was controlling memory usage, but that does not reflect on Azure's number. Also, swapping is a bit better than just having your site taken down with no warning.

* Nearly all hosting providers have "free" database providing included in their price. (And until I read that artile, I wouldn't even think on adding that "nearly" at the beggining.)

But yes, you shold know your environment, and not shoehorn it in.

Re: How Azure Web Sites Sucked in Production

#22

Post by kgreene2 »

marcosdumay wrote: post #21
callumjones wrote: post #14

Here's the take-away from this post * You treated the system's memory like it was some infinite resource. It's not, you need to make sure your application efficiently handles memory and takes measure to ensure it doesn't grow too large. Would you want it swapping on a regular host? * You thought you could get away with a free database that is used for development. You're using an application that isn't built well for…

Take-aways that must came with yours: * There is no way to calculate memory usage, it's completely opaque. The first thing the author told was how he was controlling memory usage, but that does not reflect on Azure's number. Also, swapping is a bit better than just having your site taken down with no warning. * Nearly all hosting providers have "free" database providing included in their price. (And until I read that…

I'm not sure I agree with nearly all hosting providers having free database services. Azure seems like it intends to be a competitor to AWS and Rackspace, both of which charge for their cloud databases.

AWS RDS Pricing - https://aws.amazon.com/rds/pricing/

Rackspace Cloud Database Pricing - http://www.rackspace.com/cloud/databases/pricing/

Re: How Azure Web Sites Sucked in Production

#23

Post by ahmelsayed »

pionar wrote: post #16
dav-id wrote: post #12

Earlier quoted context omitted.

Not only is the shared tier a preview product it also releases itself from memory when inactive which results in a slow warm up after this happens and a visitor lands on your site. Great for a personal blog but for a business where your customers expect things instantly, it is not so good.

> it also releases itself from memory when inactive. That's the nature of application pools in IIS. If the app pool goes inactive for a time, IIS kills the w3wp process running the app. You can set the timeout in the web.config (not in front of code right now, don't know the exact incantations). Does WAWS respect that? Though, the shutdown would be a good thing for a small site like what WAWS is intended for, because…

While that is absolutely true for IIS and the Shared tier in Azure Websites (although it's fully configurable if you own the IIS box[1]), Dedicated tiers (when you own the whole VM) in Azure have a feature called Always On[2] Where there is no idle Time-out on the app itself, so even if the app remained idle for days, w3wp process won't be killed. Also if the app happen to shutdown for any reason (machine restart, Azure Update, Windows Update, app crash, etc) Azure Websites will make sure to send a request to the app to start it up and warm it, then the app can use Application Initialization[3] to do any more complex warmup

[1] http://serverfault.com/a/595215/219792

[2] http://azure.microsoft.com/en-us/documentation/articles/web-...

[3] http://www.iis.net/learn/get-started/whats-new-in-iis-8/iis-...

Re: How Azure Web Sites Sucked in Production

#24

Post by numlocked »

I'm not sure where you expect to get great wordpress hosting for "10 times less" than $69/mo. That's not very much spend for a commercial website. Pagely, which has the scale economics advantage of doing nothing but hosting WP sites, starts at $24/mo. To hit the baseline level of "production readiness" with Heroku is going to run you at least $85/mo (2 dynos, 1 free, 1 @ $35/mo + $50/mo postgres instance).

If Azure really wasn't sending log events that memory quotas were being exceeded then I agree the alerting leaves something to be desired. But the DB quota was clearly sending "database error" log messages. Dunno what else you want them to do there.

Re: How Azure Web Sites Sucked in Production

#25

Post by callumjones »

marcosdumay wrote: post #21
callumjones wrote: post #14

Here's the take-away from this post * You treated the system's memory like it was some infinite resource. It's not, you need to make sure your application efficiently handles memory and takes measure to ensure it doesn't grow too large. Would you want it swapping on a regular host? * You thought you could get away with a free database that is used for development. You're using an application that isn't built well for…

Take-aways that must came with yours: * There is no way to calculate memory usage, it's completely opaque. The first thing the author told was how he was controlling memory usage, but that does not reflect on Azure's number. Also, swapping is a bit better than just having your site taken down with no warning. * Nearly all hosting providers have "free" database providing included in their price. (And until I read that…

I think swapping is just as bad as having the quota cut you off, both will result in your site either accepting users or not (if you're swapping you're turning users away by being slow).

Not sure what reliable hosting providers through in database for free and expect it handle 3600+ connections.

Re: How Azure Web Sites Sucked in Production

#26

Post by anilmujagic »

pionar wrote: post #16
dav-id wrote: post #12

Earlier quoted context omitted.

Not only is the shared tier a preview product it also releases itself from memory when inactive which results in a slow warm up after this happens and a visitor lands on your site. Great for a personal blog but for a business where your customers expect things instantly, it is not so good.

> it also releases itself from memory when inactive. That's the nature of application pools in IIS. If the app pool goes inactive for a time, IIS kills the w3wp process running the app. You can set the timeout in the web.config (not in front of code right now, don't know the exact incantations). Does WAWS respect that? Though, the shutdown would be a good thing for a small site like what WAWS is intended for, because…

You don't need to have external tool to keep the AppPool from timing out: right-click AppPool in IIS Manager > Advanced Settings > Idle Time-out: set to zero. Also, you don't need the script to reset it at certain time: right-click AppPool in IIS Manager > Recycling... > Specific time(s).

Re: How Azure Web Sites Sucked in Production

#27

Post by pekk »

darksim905 wrote: post #10

So because these guys are either bad at coding, had a site that was on heavy load for that service, or what else you want to call it, an entire platform isn't ready for service? Get real. From everything he told me, if I had a real site & wanted to make use of a lot of things for cheap I'd go for their free tier in a heartbeat.

HN uses this reasoning all the time. For example, "I don't know how to use language x, so language x sucks for sysadmins" or "I don't know how to use language x, so it is too slow"

Re: How Azure Web Sites Sucked in Production

#29

Post by twistedpair »

kgreene2 wrote: post #22
marcosdumay wrote: post #21

Earlier quoted context omitted.

Take-aways that must came with yours: * There is no way to calculate memory usage, it's completely opaque. The first thing the author told was how he was controlling memory usage, but that does not reflect on Azure's number. Also, swapping is a bit better than just having your site taken down with no warning. * Nearly all hosting providers have "free" database providing included in their price. (And until I read that…

I'm not sure I agree with nearly all hosting providers having free database services. Azure seems like it intends to be a competitor to AWS and Rackspace, both of which charge for their cloud databases. AWS RDS Pricing - https://aws.amazon.com/rds/pricing/ Rackspace Cloud Database Pricing - http://www.rackspace.com/cloud/databases/pricing/

Paying for provisioned performance is a pretty good idea, but the general script kiddie audience wants stuff to "just work." Obviously there is a divide between SLA quality services and bulk shared services like PHP on Dreamhost.

Re: How Azure Web Sites Sucked in Production

#30

Post by nkozyra »

codfrantic wrote: post #2

Is it actually common to limit users on cpu/memory use this way? I'd expect the limitations to simply be based on the resources made available to your processes...

Yes, it's common but handled a little more idiomatically, by presenting your available resources as VM/instance/machine. Of course, you aren't given the ability to exceed those metrics in a traditional cloud environment.
Post reply on HN