Project

General

Profile

Actions

Feature #2449

closed

max_requests_per_proc feature missing

Added by gureedo over 11 years ago. Updated over 7 years ago.

Status:
Missing Feedback
Priority:
Normal
Category:
mod_fastcgi
Target version:
-
ASK QUESTIONS IN Forums:

Description

Currently in sources of mod_fastcgi there is variable max_requests_per_proc witch says:

/*
 * some fastcgi processes get a little bit larger
 * than wanted. max_requests_per_proc kills a
 * process after a number of handled requests.
 *
*/

It's not implemented.


Files

mod_fastcgi.c.patch (6.04 KB) mod_fastcgi.c.patch patch to add missing feature gureedo, 2012-09-28 05:33
mod_fastcgi.c.patch (6.04 KB) mod_fastcgi.c.patch gureedo, 2012-09-28 13:44
lighttpd.patch (5.2 KB) lighttpd.patch gureedo, 2012-10-01 07:19
Actions #1

Updated by gureedo over 11 years ago

  • Status changed from New to Patch Pending
Actions #2

Updated by stbuehler over 11 years ago

Please use unified diffs (diff -u).

Apart from that i'm not sure i want to add that feature:
  • 1.4.x is supposed to be stable, and this feature could lead to new bugs/problems
  • i really think that feature belongs into the fastcgi backend
Actions #3

Updated by gureedo over 11 years ago

uploaded unified diff.
not all backends support this feature.

Actions #4

Updated by darix over 11 years ago

still not unified diff? uploaded the wrong file? you know the easiest thing for you would be. checkout the svn tree and run svn diff?:D

Actions #5

Updated by gureedo over 11 years ago

previous patch made by diff -u.
Attaching diff made by svn diff.

Actions #6

Updated by stbuehler over 11 years ago

  • Target version changed from 1.4.32 to 1.4.x

don't renumber existing options, append your new option.

i still don't think i'm going to apply the patch; there are may reasons to use external spawning, so the backends actually need that feature directly.

Actions #7

Updated by gstrauss over 7 years ago

  • Missing in 1.5.x deleted (Yes)
Actions #8

Updated by gstrauss over 7 years ago

  • Status changed from Patch Pending to Need Feedback

Is there still interest in this feature?

As noted above, the patch needs some work. When load is decremented, the number of requests should be checked, and the process killed iff it was started by lighttpd and exceeds the request limit. When choosing a proc, the number of requests should be checked and the proc should be skipped (ignored) if number of requests (including those in progress) exceeds the request limit.

Actions #9

Updated by gstrauss over 7 years ago

  • Status changed from Need Feedback to Missing Feedback

Keeping count of number of requests served is best done by each backend, rather than by (potentially) multiple independent front-end lighttpd workers.

Multiple options already exist to do this.

PHP_FCGI_MAX_REQUESTS can be set to have PHP backend exit after a the configured number of requests.
http://php.net/manual/en/install.unix.lighttpd-14.php

PHP-FPM is another option:
http://php.net/manual/en/install.fpm.configuration.php

 pm.max_requests int

    The number of requests each child process should execute before respawning.
    This can be useful to work around memory leaks in 3rd party libraries.
    For endless request processing specify '0'.
    Equivalent to PHP_FCGI_MAX_REQUESTS. Default value: 0.

The above are examples for PHP, but backends in other languages can also speak the FastCGI protocol, as gureedo wrote:

not all backends support this feature.

If there is still interest in this feature, then please re-open this request and provide a pointer to the fastcgi backend server which does not support restarting after a configured number of requests. Perhaps it is straightforward to fix that in the backend server, which is where the limit should be applied and enforced.

Actions #10

Updated by gstrauss over 7 years ago

  • Target version deleted (1.4.x)
Actions

Also available in: Atom