We are leaving Russia. We are against aggression and war with Ukraine. It is a tragedy for our nations, it is a nightmare

What scale do you need to have to make using Hangfire in web applications untenable?

To clarify, I know the docs go into 2 suggestions why you move into another process (consuming too much CPU or jobs that are constantly aborted).

What I want to know is what others are already doing - many people in the “Is anyone using Hangfire in production?” listed super high frequency of jobs. I’m assuming most of those were not in a web application? Besides being part of the main application, is there some sort of overhead in Hangfire for running it in a web application besides contention between the main application?

I’m using Hangfire for what I’m building and currently have it as a Windows Service through TopShelf. I’m planning on deploying to Azure in the future and am realising it is a lot more simple to have it as part of the web application (at least in terms of deployment). I just am trying to work out whether it is a good or bad idea to move it back to my web application.

To get an idea of the frequency and size of the jobs I’m running though:

  • About 1 scheduled job every 15 minutes that triggers one job per-user of the system
  • Some jobs are frequent and short lived (call an API and store the data)
  • Some jobs are infrequent and long (crawl a website per-user once a week)

So until I have several thousand users I won’t have millions of jobs per day.

So long as you can make sure your app pool is always running (to keep the BackgroundJobServer running), I can’t imagine it would matter to host inside a service or a web application. I’m hosting in a service because I have dozens of BackgroundJobServers running; a single web application wouldn’t work in my case.

I use in other projects where the worker is a single instance. While those would be OK to deploy to a web server, the environment we have at work makes it simpler to deploy and configure Windows Services instead of IIS instances.

Does that help?

Yeah, that is useful to know. I’m definitely leaning on the side to fold the codebase back into the single application as I can just deploy it as an App Service on Azure and use auto-scaling etc. Every other method I was looking at (WebJobs, Cloud Service, Virtual Machine and Virtual Machine Set) was actually a lot more hassle for both deploying and managing.

I couldn’t really imagine there was really a difference as ultimately it is the same code running but figured I’d ask all the same.