mod_cgi for nginx - anyone?
Igor Sysoev
is at rambler-co.ru
Sun Feb 8 13:11:19 MSK 2009
On Sat, Feb 07, 2009 at 09:38:41PM +0100, Manlio Perillo wrote:
> Igor Sysoev ha scritto:
> >[...]
> >
> >nginx is not general purpose server, it's rather highload server.
> >CGI is not compatible with highload: if you run Apache/CGI, then CGI
> >will became bottleneck much earlier than Apache.
> >
>
> This is not a problem from the Nginx point of view.
> Nginx should however put a limit on the number of concurrent CGI requests.
> It can use a queue to store outgoing request, and if the queue grows too
> much return a 503 Service Unavailable, setting Retry-After to a
> reasonable (computed?) value.
>
> No browser support 503 response, however.
I mean that using CGI as main response handler on highload site is useless.
CGI may be used for lowload tasks: monitoring, administration, etc. those
can be easly handled by Apache or by proxying to Apache.
> >There are two ways to implement CGI inside nginx:
> >
> >1) simple one: just fork()ing worker process that has received a request
> >for CGI and exec() a CGI program. It's simple enough, but has a lot
> >of overhead. Besides CGI programs will run with worker privilege only.
> >
>
> Nginx could use seteuid, instead of setuid.
> So that it can reacquire root privileges.
Yes, but it's not so safe as setuid().
> As for CGI support, some time ago I was trying to implement it.
> The idea was to use unix domain sockets (socketpair), and reusing the
> http_upstream module.
>
> However I gave up, a lot of code for connection/upstream setup must be
> rewritten, and I hate to write boiler plate code; and expecially having
> to maintain it :).
Yes, CGI module should use modified upstream module.
> In Nginx one can also easily close all current opened file descriptors,
> in child process; Nginx keeps all opened connection in the
> ngx_cycle->free_connections variable so one can write a closefrom function.
This can be resolved using fcntl(F_SETFD, FD_CLOEXEC) too.
--
Igor Sysoev
http://sysoev.ru/en/
More information about the nginx
mailing list