Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

Re: Pre-Forking Daemon with Parallel::ForkManager

by stevieb (Canon)
on Oct 17, 2019 at 23:35 UTC ( #11107635=note: print w/replies, xml ) Need Help??


in reply to Pre-Forking Daemon with Parallel::ForkManager

What do you mean by "pre-forking daemon"?

I've used Parallel::ForkManager in a client script that creates a set, configurable number of forks, where each fork is responsible for dispatching a set of commands to back-end daemons running on several remote listening servers and then aggregating the results, but I'm unsure of what you're wanting here.

Could you describe your situation/scenario a little bit as to what you're wanting to achieve? Or is this just something that you found interest in and desire to create a problem that you want to use P::FM to solve?

  • Comment on Re: Pre-Forking Daemon with Parallel::ForkManager

Replies are listed 'Best First'.
Re^2: Pre-Forking Daemon with Parallel::ForkManager
by hippo (Chancellor) on Oct 18, 2019 at 08:17 UTC

    What I understand by "pre-forking daemon" (or more usually, "pre-forking server") is a process with a dynamic number of forked children which manages the child pool so that there are always some idle children waiting for client requests. This is done as a compromise to improve latency without committing vast amounts of memory. If there were a set number of children (say 64) then you might have a situation where all 64 of them are sitting around doing nothing just waiting for a request and hogging memory while it happens. OTOH, if you only fork a child when a request comes in the heavy act of forking introduces latency in the response. By having a stipulated, configurable range of "spare" children you get the best of both worlds. That's the theory, anyway.

    Apache 1.x used this method and you can still run Apache 2.x this way if you choose (but most use a threaded MPM instead). PHP-FPM seems to use a similar mechanism as do some nameservers, etc.

Re^2: Pre-Forking Daemon with Parallel::ForkManager
by enemyofthestate (Scribe) on Oct 18, 2019 at 14:50 UTC

    Sure.

    I am creating a server application that receives a street address over a socket, normalizes the address, gets the co-ordinates of the property, and grabs spatial and parcel data from an Oracle database. It then returns the information in one of several formats requested by the caller. It has to handle mutiple simultaneous requests. For technical reasons related to the way the queries have to be made I prefer it to be a forking server instead of multi-threaded.

    In the past I've used a modified version of the formula in the Perl Cookbook but P::FM seems like a more elegant solution and I have used it sucessfully in several client programs. It really simplifies the fork management and that may make it easier for some future maintainer to support. The actual logic for processing the information is in its own subroutine so the desire is also one of making the code "prettier".

    Once upon a time I wrote similar programs in C so I am not completely unfamiliar with the book-keeping necessary to make this work.

      Your application sounds like a perfect use case for an application speaking REST (or not) served by one of the modern web application frameworks, e.g. Dancer2 or Mojolicious, which come with preforking servers built in. It's not necessary to build your own frameowrk for that part of your application.

      Hope this helps!


      The way forward always starts with a minimal test.

        If only :)

        For the foreseeable future, the format for the request is a pipe delimited string delivered over a socket connection. I've advocated converting to a GET or JSON format but too many legacy client programs are tied to the pipe-delimited string. That is not likely to change before I retire...

        One irony is I already wrote a fast-cgi running inside Apache. It takes a GET request, processes it and then returns a JSON formatted response.

      Maybe Minion might be of use? (disclaimer: never personally used it, just seen it mentioned browsing the Mojo docs)

      The cake is a lie.
      The cake is a lie.
      The cake is a lie.

        Maybe but Minion looks more like a client side module. OTOH, I maintain another program that may be able to take advantage of it to pool persistent database connections.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://11107635]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (4)
As of 2019-11-22 05:50 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Strict and warnings: which comes first?



    Results (108 votes). Check out past polls.

    Notices?