So I’m not allowed to use the “always on” switch?
I'm running a simple website from Azure. It's just a personal page, but still I get annoyed by the slow response of the first hit.
The main cause is obviously that nobody visits it. So Azure will unload the worker process that runs the website and reload it after it gets hit again. But little to no hits doesn’t mean I don’t want it to be fast for the first response. I need it to be really fast. If this is my only user today, I need him.
I’m running Azure from my MSDN subscription, so I actually have some money to spend. But I would rather spend it on other things than just my personal home page. The main reason I’m using Azure is to learn form it anyway. So I’m bummed out if the subscription is empty when I’ve got a new crazy idea I want to try.
To fix this, I’ve come up with a way to keep my site ‘hot’ without the need to write any code. I have to admit that I’m not yet sure what the overall cost of this solution would be. But the solution can be used for other purposes. So if you’re interested in turning some of your webpage or services into batch jobs, you should read on!
Azure provides you with a switch to keep the site ‘HOT’ at all times. The ‘Always On’ switch that you can find under the configuration of your site.
This is what it looks like on my site:
So I need to pay to have a “hot” site? But don’t you guys know I’m dutch!
So How Can We Prevent Azure from Unloading My Site?
I could of course scale up to the basic plan and start paying. Since my site doesn’t really get any hits, it won’t cost much. But where is the fun in that!
Azure provides us with a plethora in tools. Most of them are free or cost very little. There has to be one that I could use.
First, I looked at creating a webjob behind the site. It requires me to write a script, this can be anything from node.js to powershell or even just a C# program. The idea would be to have it ping the website regularly. But I’d have to make something. And I’m a lazy son of a..
The easiest tool in your Azure toolbox is the Scheduler. You can simply tell it to call any url on your site every (n) minutes.
manage.azure.com portal, you can find the tab Scheduler just below CDN and Automation.
Here, we’ll just create a new job. Click “New” in the lower left corner. You’ll have to choose Custom.
Now you’ll have to choose either an existing Job Collection or create a new one.
You can create Job Collection for different regions. If you use this by means of a ping, your site will be pinged from that specific region.
Let’s say we did pay for a scaled website, this could be useful if we distributed multiple instances of the site over the entire world.
We would probably have the always on switch on.
You can use this for other purposes! One thing I came up with is using it to fetch a page or generic handler, that does an expensive data call and places the result in cache.
This will make your ‘cache update’ generichandler both an interface a user could call on demand and a batch job.
The other thing that could be useful is fetching pages from different regions to collect statistics about your sites' latency to users in that region.
This can be useful when you need to decide if you want to deploy a copy of the site to that region.
You can use Application Insights for that. But I guess that will be a different blog.
Next, we’ll set up the job itself. We need to give it a name and choose which protocol and method we need to use. Remember that this can also be incredibly useful for firing of something like a webservice, that copies RSS feeds to a database, or whatever.
The next step in the wizard is the schedule. Here things get a bit odd. You have to choose an end date. The default is next month. You cannot make it run forever here. So just ignore it for now. We’ll fix this later.
So great. We’ve set up a job that will fetch the website every 10 minutes. This will prevent it form going idle. And it should make all the next responses snappy.
Fix the Schedule
In the previous step, we couldn’t choose for the job to run forever. This isn’t really a restriction of the job schedule. Just a restriction of the wizard. To fix this, we’ll need to go to the job settings themselves. You need to go into the job collection. And then to Jobs.
Open the right job and then under Schedule all the way down. Select ‘no end date’.
The problem I’m trying to solve here might have a better solution. But if your site isn’t hit often (yet) because you’re a startup and you still need it to be fast for first use, this might be an option.
However choosing a pay-as-you go type subscription and switching the always on switch might not cost as much on a low traffic site anyway.
What we did get out of it though is a simple overview of the Scheduler. And I think it can be used for simple batch type processing. And for instantiating cache results.
I’ve got a few scenarios where there is a lengthy operation that caches its results. You could make a webjob for this, but then it might be harder to also make this possible on user demand.
Next to that, if you have no idea how to make webjobs but you know how to create .aspx pages or generic handlers. All of a sudden, you’ll get a batch processing system, without the need to learn anything new.