我还不完全确定将如何把进程生成添加到新的 mod_proxy_core 中。目前的想法是下面描述的 mod_spawn。如果您有特定的需求或实现想法,请添加您的评论。在 mod_proxy_core 之前,mod_fastcgi、mod_scgi 和 mod_proxy 都做着相同的事情,只是协议不同。我们已经解决了这个问题。那 mod_cgi 呢?它有点不同,因为它使用管道进行通信,并使用进程环境传递 CGI 环境。但除此之外,它的工作方式相同。mod_proxy_core 不关心生成进程,它是一个代理模式。数据输入,数据输出。中间进行一些转换。但我们需要进程。CGI 为每个请求都需要一个新的进程,而 FastCGI 和 SCGI 喜欢一直保持它们运行。有些喜欢用户更改,有些在死掉时必须重新启动。最终,这与协议无关。如果你退一步看,进程生成看起来是这样的
通信通道
* FastCGI、SCGI 和 HTTP 使用套接字。可以是 TCP 或 Unix 域套接字。* CGI 使用 2 个管道
关闭前请求的数量
* CGI 在请求结束时终止,不重新启动。* 其他的更倾向于保持活跃。所有这些都必须在我们可以与它们通信之前启动。
可能的配置
我考虑了如何配置生成,并得出了以下方案
## FastCGI spawning
$HTTP["url"] =~ ".php$" {
var.backends = ( "127.0.0.1:1026", "127.0.0.1:1027" )
spawn.bin-path = "/usr/bin/php-cgi"
spawn.socket-type = "socket"
spawn.socket-name = var.backends
spawn.environment = ( "PHP_FCGI_CHILDREN" => "16" )
## terminate the number of requests to the process to 1000
spawn.max-requests = 1000
proxy-core.protocol = "fastcgi"
proxy-core.backends = var.backends
}
我们生成一个 PHP 进程,带有 16 个工作进程,监听 TCP 套接字
127.0.0.1:1026。由于这是一个基于套接字的进程,我们会自动保持它活跃。如果我们需要在需要时启动进程或一直保持其运行,我们可能会添加一些微调。对于共享主机环境,为了节省内存,关闭它们可能更有意义。对于 CGI,情况类似。我们有一个 spawn.environment 用于向进程环境传递变量,我们有一个 bin-path 用于调用脚本解释器,等等。
## CGI spawning, self-executing
# old
$HTTP["url"] =~ "^/cgi-bin/" {
cgi.assign = ( "" => "" )
}
# new
$HTTP["url"] =~ "^/cgi-bin/" {
spawn.socket-type = "pipe"
spawn.environment = ( "TRAC_ENV" => "lighttpd" )
proxy-core.protocol = "cgi"
}
## Perl-CGIs
# old
cgi.assign = ( ".pl" => "/usr/bin/perl" )
# new
$HTTP["url"] =~ "\.pl$" {
spawn.bin-path = "/usr/bin/perl -wT"
spawn.socket-type = "pipe"
proxy-core.protocol = "cgi"
}
为什么?
为什么所有这些新东西?因为我们有大量的代码重复,整理这些代码是个好主意。特别是对于 CGI 代码的 Windows 移植,我们需要一个集中的地方来生成进程。
那旧的 mod_fastcgi 呢?
我认为所有旧模块(mod_fastcgi、mod_scgi、mod_cgi、mod_proxy)都将在 1.5.0 中被弃用。它们的代码现在在不同的模块中,并且不再需要。但是删除它们会吓跑所有现有用户。计划是将所有这些模块转变为 mod_proxy_core 的前端模块。它们将保留旧的配置语法,但会将配置下推到 mod_proxy_core 和 mod_spawn 中。
那 suEXEC 呢?
suexec 只需要 spawn.bin-path 和 spawn.environment 即可工作。它将适用于所有后端进程,而不仅仅是像现在这样仅适用于 FastCGI。
现在呢?
现在,我需要您的评论。这有意义吗?这个想法缺少什么?