3

I'm using Hang Fire in my Asp.Net Core web API application which is deployed in azure app service.

We need to run few jobs which is CPU intensive and long running ones. Is it ok to create a different App Service and deploy a completely new project which will just run the jobs in that app service? But this will be connected to the same database to which the other App service is connected. Is this ok or will be an issue?

Thanks, Joe

Joe Samraj
  • 311
  • 3
  • 21
  • 1
    You shouldn't use ASP.NET Core for this (its not clear in your question if you intend to run it in its own ASP.NET Core app), since web applications tend to be closed/shut down at any point (low resources, idle, configuration reload) by IIS, even when setting the idle time up there's no guarantees. You should rather use Background Tasks (aka WebJobs) for this – Tseng Oct 04 '18 at 13:05

1 Answers1

2

If you are scheduling jobs from within the web app, using Hangfire, the Hangfire poller might keep the app busy enough to never idle out. Failing that, enabling Always-On should prevent any (non-catastrophic) shutdowns, so the poller can always run.

But, if you're like me, you or your customers want the app to spin down when it can. So, you can schedule your tasks using WebJobs or other Azure platform scheduling & queuing tools instead, tools made for just your scenario. The WebJob can trigger a task which Hangfire manages for persistence only, not for scheduling. The managed task code can live in the original web app.

In other words, if you're creating a separate App Service because you're worried about reliability in your web app, or because you think it's a best practice, I'd say don't bother.

On the other hand, if you know you're OK with the added complexity and potential costs of deploying another App Service, and you have your reasons for doing so, I think it's fine. With a separate app, you'd have the ability to restart or shut down one without taking down the other.

Noah
  • 417
  • 1
  • 5
  • 10