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

Posted by viatropos on Stack Overflow See other posts from Stack Overflow or by viatropos
Published on 2010-06-02T19:28:56Z Indexed on 2010/06/02 19:34 UTC
Read the original article Hit count: 104

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?

© Stack Overflow or respective owner

Related posts about ruby

Related posts about best-practices