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.
