projectkudu / kudu

Kudu is the engine behind git/hg deployments, WebJobs, and various other features in Azure Web Sites. It can also run outside of Azure.
Apache License 2.0
3.12k stars 654 forks source link

Limit the number of instance of a continuous webjob #2504

Closed stewart-r closed 4 months ago

stewart-r commented 7 years ago

It would be great to be able to limit the number of instances of a webjob.

See this Stack Overflow question and this one

Whilst I know we can make a continuous webjob a singleton using the settings.job file , it would be useful to also be able to limit the number of instances to a number other than 1. To my knowledge, no such functionality exists?

My use case is an app service plan set to scale out based on CPU usage and a continuous webjob triggered from a queue. When we get a glut of queue messages, the webjob uses up the cpu resource and triggers a scale out but the next instance quickly also grabs messages from the queue, gets up to high CPU and triggers another scale, etc.

As it stands, the only fix is to make this webjob a singleton and avoid more than one scale out directly resulting from the glut of queue messages. This works really well, so far as it goes, but sometime it may be appropriate to balance the time taken to get through the queue messages and have a few instances of the webjob but still allow the app service plan in general to scale out further.

davidebbo commented 7 years ago

I confirm that WebJobs don't support this.

However, not that the WebJobs SDK (a separate piece) supports limiting the concurrency that it uses via BatchSize & NewBatchThreshold. This should help prevent a burst from overwhelming one instance.

stewart-r commented 7 years ago

@davidebbo Thanks very much for taking the time to confirm this is the case (which I suspected). I know about the batch options in the webjobs sdk but I'm not sure they are able to solve the issue.

In the event of a queue message glut we want enough concurrency to fully utilise the CPU resource on a 'small number' of instances but also to have the service plan auto scale out to a slightly larger number of instances to keep the other apps in the service plan responsive.

To my knowledge, the batch options available in the webjob SDK configure batchsize/threshold at webjob start up only and are not reactive so I can't see a way to utilise that feature to resolve our issue. Maybe I am missing something? or trying to fit a square per in a round hole?

The is_singleton setting works perfectly if it so happens that we'd want the 'small number' to be 1. In this case the app service plan scales out but the webjob doesn't and everything works as expected. If this is the use-case for an is_singleton setting (is it?) then would it not be feasible to have a max_instances instead?

davidebbo commented 7 years ago

@stewart-r your understanding of is_singleton is correct. What you suggest about it supporting values other that 1 or all certainly makes sense, but is not supported today. That's why I was trying to suggest 'approximations' based on other features that exist (but it's not quite the same).

Yes another approach is to use a separate App Service Plan for the WebJobs, so it's not tied to other thing (though of course there is a cost factor).

jvano commented 4 months ago

Hi

If the problem persists and is related to running it on Azure App Service, please open a support incident in Azure: https://learn.microsoft.com/en-us/azure/azure-portal/supportability/how-to-create-azure-support-request

This way we can better track and assist you on this case

Thanks,

Joaquin Vano Azure App Service