* 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 shared environments, it expects dedicated hosting.
You'd be better off designing your blog around Azure Web Sites, knowing the advantages and disadvantages of the platform and taking advantage of them. Don't try to shoehorn it in.
* 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.
AWS RDS Pricing - https://aws.amazon.com/rds/pricing/
Rackspace Cloud Database Pricing - http://www.rackspace.com/cloud/databases/pricing/
Not sure what reliable hosting providers through in database for free and expect it handle 3600+ connections.
But I'm a tech guy. As a customer, I would expect Azure to configure the server and PHP on its own and not bother me with the quotas at all :)
* We did not develop the application from scratch and therefore we cannot control its memory consumption, especially if it's a garbage-collected environment. We used WordPress as an existing application template provided by Azure. The development on our side was only about developing a custom WP theme, which is 90% frontend development. The developers barely touched the server side, and we tried to configure the environment to consume not more than X MB.
* Regarding not being built well for shared environments: WordPress powers about 60 million sites in the world, and I bet the vast majority of them runs on a shared hosting. Currently, this blog post is served from one of them :) During the typical days, our traffic is really too low for a dedicated environment, so it would really be an overkill.
[1] http://azure.microsoft.com/en-us/pricing/details/web-sites
Great for a personal blog but for a business where your customers expect things instantly, it is not so good.
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 when the site isn't running, it's not still using resources.
In my company's environment (our own datacenter), our monitoring tools keep the app pool from "timing out" because it hits a status page every 2 minutes. We manually (through a script) recycle app pools at a given time every night.
[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-...
Good, bad, why would you use it?
My hunch is that anything that actually needs to tap out 512MB of RAM should be running on a plan that's more than $10/month.
Azure doesn't configure it for you because it assumes you're knowledgeable. It reacts more harshly than I'd like for sure if you go over, but expecting you to do your work (for cheap) doesn't seem unreasonable to me.
Azure web sites uses a .user.ini file to setup php.
See the documentation here: http://azure.microsoft.com/en-us/documentation/articles/web-...
So these are two completely unalike resources that should be treated very differently. A process routinely overusing CPU can simply be capped to a certain rate (I assume you can do this on Windows) but a process that grows too large should simply crash. It doesn't make any sense to take down an application for an hour because it used to much memory.
I suspect that the reason for this enforcement is that Azure has taken some liberties with the isolation between sites and they can't figure out how to charge resources properly. But that is their problem and it shouldn't leak out through the interface and harm the customer.
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.
this holds all the way down to $0 (free), in which case, the customer is almost never satisfied. because they're getting almost no value for no money.
I haven't fully made it 'live' yet, but this gives me some pause whether I should. I think the WAWS platform is good overall, but there is probably too many layers of 'magic' happening under the skirt for this to be a great solution yet.
If your CMS is caching, big memory footprint and some DB thrashing. If you aren't caching, big DB thrashing and some memory consumption.
I'd like a little more flexibility with the lower tiers since I've been "quotad" by memory limits when caching goes bonkers during CMS updates. Something like short-term overage allowances with warnings.
Its not cheap hosting (I'm running a business so I just want my stuff all in one place) but it has been very solid when used at Standard with a paid MySQL database option (the free tier is for development - not production).
I see what they did there
