# What scale do you need to have to make using Hangfire in web applications untenable? **URL:** \ **Category:** meta\ **Created:** [October 28, 2018, 1:59am UTC](https://discuss.hangfire.io/t/what-scale-do-you-need-to-have-to-make-using-hangfire-in-web-applications-untenable/5504 "2018-10-28T01:59:50Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Turnerj](https://avatars.discourse-cdn.com/v4/letter/t/f9ae1b/32.png) [@Turnerj](https://discuss.hangfire.io/u/Turnerj)\ **Post date:** [October 28, 2018, 1:59am UTC](https://discuss.hangfire.io/t/what-scale-do-you-need-to-have-to-make-using-hangfire-in-web-applications-untenable/5504/1 "2018-10-28T01:59:50Z")
To clarify, I know [the docs](http://docs.hangfire.io/en/latest/background-processing/placing-processing-into-another-process.html) 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?”](http://hangfire.discourse.group/t/is-anyone-using-hangfire-in-production/468) 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. ---
**Author:** ![hometoast](https://dub1.discourse-cdn.com/flex017/user_avatar/discuss.hangfire.io/hometoast/32/688_2.png) [@hometoast](https://discuss.hangfire.io/u/hometoast)\ **Post date:** [October 29, 2018, 1:40pm UTC](https://discuss.hangfire.io/t/what-scale-do-you-need-to-have-to-make-using-hangfire-in-web-applications-untenable/5504/2 "2018-10-29T13:40:21Z")
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? ---
**Author:** ![Turnerj](https://avatars.discourse-cdn.com/v4/letter/t/f9ae1b/32.png) [@Turnerj](https://discuss.hangfire.io/u/Turnerj)\ **Post date:** [October 30, 2018, 11:51am UTC](https://discuss.hangfire.io/t/what-scale-do-you-need-to-have-to-make-using-hangfire-in-web-applications-untenable/5504/3 "2018-10-30T11:51:25Z")
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.