in reply to Re: How to fork in PSGI/Dancer2 (daemonize)
in thread How to fork in PSGI/Dancer2

That sounds like a fine and practical solution.   The general problem with “daemonizing,” of course, is that the number of processes/threads will equal the number of active web requests, more or less.   If the number of requests is small, infrequent, etc., that’s all well and good.   But if the work to be done is “beefier” and there might be a large number of requests coming in to do such work, that’s specifically when I suggest that you should separate the two concerns.   Let the web strictly be a user-interface, to a separate workload-handling (background) activity which can be separately throttled.   Even if 1,000 requests to do some work, came in all at once, the system would still be able to apportion the work so that no more than some-n of those requests would be in-process at one time, on some number of servers.   The known worst-case completion times would not become “worse yet,” even though the waiting-lines might briefly have stretched out into the hallway.   The system would be briefly swamped, but not drowning.

And none of this actually has any bearing on PSGI / FCGI / CGI / mod_perl or any other website implementation concern.

Replies are listed 'Best First'.
Re^3: How to fork in PSGI/Dancer2 (daemonize)
by Anonymous Monk on Jan 30, 2015 at 22:12 UTC

    That sounds like a fine and practical solution. The general problem with “daemonizing,” of course, is that the number of processes/threads will equal the number of active web requests, more or less

    Sure it isn't -- why would you daemonize for every request? That sounds like PEBKAC