FCGI :: ProcManager module development

Some time ago, in the company in which I now work, it was decided to optimize the performance of server applications. Initially they were used in the nginx + apache + mod_fastcgi or mod_fcgid bundle. However, I wanted to get rid of apache, given that nginx can work with FastCGI applications by itself.

In the process of solving this problem, I wrote a module-successor from the FCGI :: ProcManager module. A functionality has been added to it to control the number of working processes depending on the workload and to limit the lifetime of the working processes to a certain number of requests.
The latter possibility is already implemented, including by the author of FCGI :: ProcManager, but I did not find a flexible management of the number of processes. That's why I decided to add functionality to the above module.

The FCGI :: ProcManager :: Dynamic module implements the described advanced functionality for managing FastCGI processes. To monitor the number of work processes by the main process, their interaction is used through message channels in shared memory.
')
The following advanced options are supported:
max_nproc - the maximum number of worker processes;
min_nproc - the minimum number of working processes;
delta_proc - “step” when changing the total number of processes;
delta_time - time elapsed since the last change in the number of processes, after which, at low load, the number of working processes will be reduced. Such a decrease occurs only if during the whole of this period the number of processes exceeding the new number of processes after its decrease was not simultaneously engaged. This is necessary in order to avoid a premature reduction in the number of processes in a high-loaded application during load fluctuations.
max_requests - the maximum number of requests for one workflow. After it is exceeded, the workflow correctly ends (see below) and the process manager creates a new workflow instead.

In connection with the introduction of a limit on the number of requests for the workflow, I would like it to be able to correctly complete the working cycle of the FastCGI application, for example, to close connections to the database. For this, an additional function pm_loop was created. When it is used, the exit from the FastCGI run-time cycle of an application is performed in the usual way and all the code located behind this cycle is executed. An example of use is in the documentation:

  $ proc_manager-> pm_manage ();
 while ($ proc_manager-> pm_loop () && (my $ cgi = CGI :: Fast-> new ())) {
         $ proc_manager-> pm_pre_dispatch ();
         # ... handle the request here ...
         $ proc_manager-> pm_post_dispatch ();
 };
 # ... here are all the final steps ...

This module is already working on production servers for about two weeks. The term, of course, is small, but given the fairly large load and the absence of failures, we can say that while he is coping.

The module is available in CPAN. Comments, tips and improvements are welcome.

I would like to thank Havrauzer Kavkaz , because, to a large extent, it was his article that prompted me to create this module.