11–20 of 48 posts
[1] http://azure.microsoft.com/en-us/pricing/details/web-sites
Besides the fact that you are using the free ClearDB plan which is not supposed for production use (and it is not related to Microsoft anyway), Azure website (shared) is a preview product [1], with no SLA, you should not consider them for any serious use anyway, so you've made two mistakes here. [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.
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.
* 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.
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.
Besides the fact that you are using the free ClearDB plan which is not supposed for production use (and it is not related to Microsoft anyway), Azure website (shared) is a preview product [1], with no SLA, you should not consider them for any serious use anyway, so you've made two mistakes here. [1] http://azure.microsoft.com/en-us/pricing/details/web-sites
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.
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.
I see what they did there
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...
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.
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.