On Thu, Oct 9, 2014 at 2:14 PM, Devin Ben-Hur <[email protected]> wrote: > On 10/9/14, 9:45 AM, Michael Fischer wrote: >> >> On Thu, Oct 9, 2014 at 5:24 AM, Bráulio Bhavamitra <[email protected]> >> wrote: >> >> I'm quite amazed of how preloading and fork and reduce memory usage. >>> >>> Making it use even less memory and restarting the app faster, the next >>> step would be incorporate other daemons (also part of the app, in my >>> case delayed_job and feed-updater) AS unicorn workers. >> >> >> As your friendly neighborhood service engineer, my experience is that >> separating the concerns (keeping asynchronous processors separate from >> your >> synchronouous web services) is worth the additional memory and processor >> cost. The two usually don't scale at the same rate, and you want to keep >> your failure domains separate as well: you don't want a bug in the async >> processor cause your web server to crash as well. And let's not even get >> into the programming and maintenance challenges. > > > Excellent points Michael. But to Bráulio's original request, it would be > lovely to factor out the clean and robust process management parts of > unicorn (daemonization, pidfile-mgmt, pre-load, fork, reap, signaling) > separate from the HTTP/Rack server. This would give us a robust supervisor > for asynchronous workers that reduce memory footprint with CoW and responds > to a well understood set of signals for management.
That would be great! If unicorn's server except HTTP specific code could be extracted into a separate gem it would be fantastic :)
