611 votes
Provide a way to schedule worker roles so they only run when needed
If worker roles could be scheduled, like windows task scheduler then we would massively reduce the required cpu time used.
If worker roles could be scheduled, like windows task scheduler then we would massively reduce the required cpu time used.
butterball
we need DTS/SSIS to schedule jobs!
Dave Bacher
Seems like it would be relatively easy to write a service that crossed .NET Terrarium (download an assembly and run it in an already warm instance) and crontab (schedule jobs to run at a particular time).
While it would be better if Microsoft did it, someone could write a service that allowed you to zip a control file and a .NET assembly. The control file would indicate the desired 4 hour block to schedule it in, and would also contain any necessary API URL's and keys.
The service would fire up at... more
Seems like it would be relatively easy to write a service that crossed .NET Terrarium (download an assembly and run it in an already warm instance) and crontab (schedule jobs to run at a particular time).
While it would be better if Microsoft did it, someone could write a service that allowed you to zip a control file and a .NET assembly. The control file would indicate the desired 4 hour block to schedule it in, and would also contain any necessary API URL's and keys.
The service would fire up at the start of a four hour block, and download 16 jobs to do. It would run each job, in turn, and if the job took longer than 15 minutes, it would be terminated.
Then you sell that service to the 315 people asking for this at some reasonable price.
(note: you could also sell the remaining hours on a compute-hour basis using a similar approach..)
Frederick Thompson
@Steven nagy - again, we run a process for 1 hour a day. we have to use an entire worker role running 24 hrs a day to make this viable. we want it in a worker role for single point of failure logic. why should we have to pay for 24 hours a day for 1 hours usage ? This is a critical feature and relevantly should be implemented as part of a dynamic deployment and removal of worker roles via the Service API. they have more than 1 team you know ?
andy.scott12
there is no way this is a waste of time. we currently have a worker running 24 hrs a day - at a cost of $88 per month just for a process that runs once a day but for single-point-of-failure - something we don't want to run in our core web role. this means we pay for 24 hours of usage - even though we run the process for 30 mins a day ?
Steven Nagy
Autoscale samples are prolific. I don't see a need to waste the Azure team's time on this feature. I'd prefer to see more services such as email and distributed cache as a service. Cheers.
offbeatmammal
I'd love to be able to reduce the cost of running roles. I have a worker role than I only need to spin up when there are blob(s) that the web roles are writing that processing.
If there was an option to suspend the worker role unless certain conditions were met (eg more than 5 blobs available or "at least 15 mins since last run and a blob available") otherwise keep the role suspended (and not costing me compute!)
Ronny Hansen
I would like the "pay for actual CPU usage" feature for worker roles that is idle most of the time, or the possibility to pause/resume the role from a scheduler - all to reduce cost of the Azure hosting.
Ravindranath Hampole
I vote for this feature. Like windows scheduler, I would like to run an app on a certain time of the day.
azurecoding
Isn't this a service that a third party can provide on top of azure? I'd prefer Microsoft provide solutions that ONLY microsoft can provide. .NET 4 test bed only Microsoft can do that. Compute Slices...another party can provide a service on top of azure that will handle that.
aaronsilvas
I'd like to see something a little more elegant. Keep the existing worker roles, and simply add a new (optional) configuration key "queueDrivenWorker", which takes a queue name to subscribe to, and other optional parameters to indicate how fast worker roles can be spun up to meet backed up queues. I could write a lot on the performance handling, but that goes beyond the scope of this point. This way workers can be spun up based on an existing azure service, queues. As work comes up, workers get... more
I'd like to see something a little more elegant. Keep the existing worker roles, and simply add a new (optional) configuration key "queueDrivenWorker", which takes a queue name to subscribe to, and other optional parameters to indicate how fast worker roles can be spun up to meet backed up queues. I could write a lot on the performance handling, but that goes beyond the scope of this point. This way workers can be spun up based on an existing azure service, queues. As work comes up, workers get to work. This is not only useful for the "2-4 tasks a day" scenario, but just as useful for scaling up based on load (10 queue/sec at 2am versus 10000 queue/sec at 2pm).
Robert Shurtleff
There is a huge gap between the originally suggested dynamic service enablement and a general purpose cloud-based scheduling feature. I would guess that Microsoft would suggest that a cloud-based scheduling feature is better facilitated by a partner solution. As for dynamic service enablement, this does seem more in the venue of azure framework itself. This would be like non-dedicated compute. Perhaps similar to how shared-sites work with most IIS hosting providers.
nisbus
How about a simple cron job implementation that would be handled by the fabric?
I have a job that runs every day and collects data from an external web site and stores it in SQL Azure. Today I'm using an ASP.NET site that offers cron job scheduling and the cron job just hits the page once a day. Hosting of the ASP.NET site is about $10 a month while the equivalent price on Azure would be close to $90 a month. Running a worker role with an internal timer sounds a bit lame for the same result and having a... more
How about a simple cron job implementation that would be handled by the fabric?
I have a job that runs every day and collects data from an external web site and stores it in SQL Azure. Today I'm using an ASP.NET site that offers cron job scheduling and the cron job just hits the page once a day. Hosting of the ASP.NET site is about $10 a month while the equivalent price on Azure would be close to $90 a month. Running a worker role with an internal timer sounds a bit lame for the same result and having an external application to spin up an instance once a day takes the application out of the cloud (partly) an thus renders reliability a problem.
Thanks
nisbus
Patrick Simpson
I put up a request for something that would provide the same benifits:
Allow simple Managed Tasks to run distributed within the Cloud and pay for CPU time used (ie NO VMs)
Mike Wickstrand
Thanks Brian, I appreciate you jumping in here and explaining why you *might* use this functionality if it was available to you.
Mike
brian
my need is as you suggested, a task that runs for 5 mins once every 24hours does not need to role deployed for 24 hours. We could use the new management api to stop the role and start it again but that would require an external client app, which introduces a single point of failure
Mike Wickstrand
Thanks for suggesting this. Can you please help me understand this one a bit more and your motivation for including it? With Windows Azure compute hours are determined based upon when your application is deployed (machine time), not CPU time. Was the primary motivation for suggesting this that by doing so you thought you would be reducing the cost to run your service on Windows Azure (or something else)?
Thanks for clarifying - Mike
anonymous
Inter role communication
Wally
fyi, i've been using System.Timers.Timer to perform this type of operation. There's no pretty ui, but I can configure things.