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.

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.