10

There are 3 ways to deploy a new function via web job:

  1. Create a new web app, and deploy a web job with the function in it.
  2. Add a new function to an existing web job (so now you have multiple functions in one web job).
  3. Add a new web job to a web app (so now you have multiple web jobs in the same web app).

All web jobs and web job functions that are on the same web app are hosted on the same VM, so maybe the material impact of all 3 is the same. But I wonder what is the difference.

What guidance is there for deciding how I should add a new web job function to my cloud solution?

  1. New web app with web job
  2. or new web job in an existing web app with other web jobs
  3. or a new function in an existing web job with other functions.

I'm interested in how it works, guidance, best practices, and performance impact of these 3 options.

Thomas
  • 24,234
  • 6
  • 81
  • 125
richard
  • 12,263
  • 23
  • 95
  • 151

2 Answers2

10

This is a hard question to answer and I try'll to give you some clues. Here is few things that you should keep in mind:

  • performance: If you put every in the same job, the jobhost will create a new thread every time one of your functions is invoked. Having too many threads in the same process can hurts performance. My choice would be to limit the number of threads running in the same process. If you google "Multithreading vs. Multiprocessing", you'll find some great answers about this. Anyway there is no general guideline and you should use a profiling tool to help you deciding what is the best solution in your case.

  • Crash: Let's say you have 2 functions in the same job. If one function crashes, it may crash the whole job. So you may need to create separate jobs to isolate functions that need to be resilient and run all the time.

  • Configuration: Multiple jobs in the same web app can share configuration (App Settings). Depends on how you manage your configuration (from the portal or using app.config) you may need to create separate web app for jobs that do not have the same configuration.

  • Deployment: When you deploy a webjob inside a webapp, it will cause the webapp to restart. If you have a web site or another job that have to keep running, you may need to create a separate web app so that new deployment of a particular component does not impact the availability of the other components.

  • "Scaling": Webjobs will run on all the instances of you app service. You can specify a particular job or a particular function to be a singleton. This is also something that you should keep in mind.

Otherwise you may be interested in Azure Functions. It uses a dynamic app service plan that scales automatically and you only pay when you functions are running. Each function are independent so you don't have to worry at all :-)

Thomas
  • 24,234
  • 6
  • 81
  • 125
  • Thanks Thomas, that's the kind of answer I was looking for. So every time a function is invoked, a new thread is spun up. So if I have a continuous webjob with 2 functions, then there will be 2 threads? Or 1 thread? – richard Oct 27 '16 at 23:08
  • Are we talking about triggered functions ? – Thomas Oct 27 '16 at 23:53
  • Yes, continuous, triggered functions (like triggered by a blob or queue). – richard Oct 28 '16 at 05:20
  • So every time a new message (new blob, new message in your queue) a new thread is spint up. But this is configurable: depends on how many messages you want to handle concurrently. – Thomas Oct 28 '16 at 05:39
  • Hi Thomas, so the web job runs and polls continuously, and then when it detects a new message it will spin up a new thread to run the appropriate function? – richard Oct 28 '16 at 16:24
  • Yes. You can configure the maximum number of message that the job will handle in parallel – Thomas Oct 29 '16 at 02:38
  • I see. The default is 16 right? For some reason I thought that meant it would grab and handle 16 at a time but in the same process/thread and in serial. – richard Oct 29 '16 at 02:47
  • Great answer, not quite correct, a small but important detai: webjobs will NOT run simultaneously on all instances if they are triggered - they will only run one at a time. Continuous jobs will run multiple. There is an app setting to instruct a webjob to be singleton in this case. – Sentinel Mar 23 '17 at 09:33
  • deployment of multiple webjobs using pipeline on same app service is removing all and only having the last one present. Can anyone help me out. – user27178 May 22 '20 at 11:10
2

As I know, you could leverage WebJobs to execute custom jobs based on different types (scripts, executable programs, etc.) within the context of a web app. In order to minimize the impact of WebJobs on the performance of the web app, you could try to create an empty Azure Web App in the new App Service Plan to host your WebJobs which could do some long-running workflows, I/O-intensive jobs, CPU-intensive jobs, etc. I recommend that you could refer to best-practices-background-jobs. Also, there is a related thread about Azure Webjobs: One Job with several Functions, or several Jobs with 1 function each, you could refer to it.

Community
  • 1
  • 1
Bruce Chen
  • 18,207
  • 2
  • 21
  • 35
  • Thanks. But I'm looking for how these all work together in terms of the VM resources so that I can make decisions based on high-volume/low-volume scenarios. – richard Oct 27 '16 at 06:28