Clarifying... So Background Jobs don't Tie Up Application Resources (in Rails)?

Question

I'm trying to get a better grasp of the inner workings of background jobs and how they improve performance.

I understand that the goal is to have the application return a response to the user as fast as it can, so you don't want to, say, parse a huge feed that would take 10 seconds because it would prevent the application from being able to process any other requests.

So it's recommended to put any operations that take more than say 500ms to execute, into a queued background job.

What I don't understand is, doesn't that just delay the same problem? I know the user who invoked that background job will get an immediate response, but what if another user comes right when that background job starts (and it takes 10 seconds to finish), wont that user have to wait?

Or is the main issue that, requests are the only thing that can happen one-at-a-time, while on the other hand a request can start while one+ background jobs are in the middle of running?

Is that correct?

Answer 1

The idea of a background process is that it takes care of all the long running processes.

Basically, it is an external application that is running outside of the webserver with one or several processes that handles the requests.

So, it doesn't matter if there is another user requesting a page since it the job is not occupying the webserver, the user will not have to wait for anything to finish.

If that user also do something that is being put in the background queue, then it will just stack up there until the first one is finished (or in the case where there are multiple processes handling it, as soon as there is one available).

Hope this explanation makes it a bit more clearer :)