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


#1

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.


#2

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?


#3

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.