Mailing List Archive: Apache: Dev

Fastcgi, use something like spawn-fcgi?

Index | Next | Previous | View Threaded

Brian.Akins at turner

Oct 29, 2009, 6:16 AM

Post #1 of 6 (224 views)
Permalink

Fastcgi, use something like spawn-fcgi?

With all the discussion of mod_fcgid lately (I admit, I did not read all the
threads, so forgive me if we already discussed this), I was wondering if a
different approach would be better.

I know at one time there was work on a mod_proxy_fastcgi. The current trend
in "other webservers" seems to do the proxying inside the webserver and
using a separate small process manager - something like spawn-fcgi or
supervisord.

So, we could have configs something like:

ProxyPass /myapp fastcgi:///path/to/my.sock max=6 ...

And should easily be able to do fasctcgi over tcp, etc.

This should, hopefully, simplify the "in httpd" code.

Just thinking...

--
Brian Akins

trawick at gmail

Oct 29, 2009, 6:50 AM

Post #2 of 6 (218 views)
Permalink

Re: Fastcgi, use something like spawn-fcgi? [In reply to]

On Thu, Oct 29, 2009 at 9:16 AM, Akins, Brian <Brian.Akins[at]turner.com> wrote:
> With all the discussion of mod_fcgid lately (I admit, I did not read all the
> threads, so forgive me if we already discussed this), I was wondering if a
> different approach would be better.

Thus far the mod_fcgid activity has been focused on resolving some
existing problems and establishing the new home. There are some new
configuration capabilities though. There's a fair amount of
mechanical work to make it a well behaved module overall.

> I know at one time there was work on a mod_proxy_fastcgi. The current trend
> in "other webservers" seems to do the proxying inside the webserver and
> using a separate small process manager - something like spawn-fcgi or
> supervisord.
>
> So, we could have configs something like:
>
> ProxyPass /myapp fastcgi:///path/to/my.sock max=6 ...
>
> And should easily be able to do fasctcgi over tcp, etc.
>
> This should, hopefully, simplify the "in httpd" code.

AFAIK mod_proxy_fcgi in trunk actually works, though I haven't tried it.

Just my 2cents: In general the idea of using mod_proxy_fcgi +
separate process manager works for me, though I am more anxious at the
moment to try to help the relatively large user base of mod_fcgid
users adopt the new 2.3.x series, and help see that whatever mod_fcgid
2.2 patches have been floating around since 2007 get properly
evaluated and resolved as appropriate.

There has been some interest expressed on this list from the mod_fcgid
user community to manage processes differently (e.g., independent of
load); in general, I'd like to see the proxy+process mgr solution
support requirements that would otherwise twist mod_fcgid in new
directions.

Brian.Akins at turner

Oct 29, 2009, 8:24 AM

Post #3 of 6 (217 views)
Permalink

Re: Fastcgi, use something like spawn-fcgi? [In reply to]

On 10/29/09 9:50 AM, "Jeff Trawick" <trawick[at]gmail.com> wrote:

> There has been some interest expressed on this list from the mod_fcgid
> user community to manage processes differently (e.g., independent of
> load); in general, I'd like to see the proxy+process mgr solution
> support requirements that would otherwise twist mod_fcgid in new
> directions.

The nginx community just recently released some glue between nginx and
supervisord that looks interesting.

--
Brian Akins

albert.lash at docunext

Oct 30, 2009, 10:29 AM

Post #4 of 6 (203 views)
Permalink

Re: Fastcgi, use something like spawn-fcgi? [In reply to]

> With all the discussion of mod_fcgid lately (I admit, I did not read all
> the
> threads, so forgive me if we already discussed this), I was wondering if a
> different approach would be better.
>
> I know at one time there was work on a mod_proxy_fastcgi. The current
> trend
> in "other webservers" seems to do the proxying inside the webserver and
> using a separate small process manager - something like spawn-fcgi or
> supervisord.
>
> So, we could have configs something like:
>
> ProxyPass /myapp fastcgi:///path/to/my.sock max=6 ...
>
> And should easily be able to do fasctcgi over tcp, etc.
>
> This should, hopefully, simplify the "in httpd" code.

Hi Brian,

Thanks for posting this, I have some experience to share, hopefully it
will be useful.

The process you describe is indeed how nginx (and I think Lighttpd) does
it. I've used it a bunch with nginx and it works fine but I actually like
mod_fcgi better. The process management was a little tricky to figure out
at first (DefaultMinClassProcessCount has to be set to 0?):

http://www.docunext.com/wiki/Mod_fcgid#mod_fcgid_Configuration

But in the end, it is awesome for containing memory leaks and
automatically re-spawning fastcgi processes. To be more explicit, in my
experience when memory constraints are not an issue (>128MB total?), I've
found Apache2 + mod_fcgid to be a far superior solution to all the
alternatives I've tried.

With spawn-fcgi, I've found I have to either program-in process management
features into the fastcgi app, or use cron, spawn-fgci and/or a process
manager to deal with stopping and starting the processes.

I've also tried out another approach which uses nginx's failover
capabilities to try connecting to the fastcgi socket (either unix or tcp).
It if fails, it connects to thttpd or mathopd to spawn a cgi process which
kickstarts the fastcgi process again. Its "hacky" and AFAIK only works
with fastcgi apps that are cgi compatible, but in the end it was actually
fairly reliable.

My next experiment will be with the cgi-fcgi bridge, which I just learned
can spawn fastcgi processes like spawn-fcgi, though as I'm writing this
I'm not sure if it can set them up to listen on unix sockets.

In closing, I'll add that I'm greatly appreciative of both Apache and
mod_fcgid and was thrilled when I learned that mod_fcgid was getting
merged into the Apache code base.

Hope that helps!

- Albert
--
http://www.docunext.com/

albert.lash at docunext

Oct 30, 2009, 10:37 AM

Post #5 of 6 (203 views)
Permalink

Re: Fastcgi, use something like spawn-fcgi? [In reply to]

> There has been some interest expressed on this list from the mod_fcgid
> user community to manage processes differently (e.g., independent of
> load); in general, I'd like to see the proxy+process mgr solution
> support requirements that would otherwise twist mod_fcgid in new
> directions.
>

I concur. Supporting them both would be excellent! I've found two separate
circumstances where I chose fastcgi as appropriate:

* Sophisticated, extensive applications which don't have memory leaks and
are meant to run all the time, like software-as-a-service solutions. I
would use an external process manager here to make sure the application is
always running and not a zombie.

* Embedded applications which run on processor and memory constrained
systems. I think a perfect example of this is the pfSense webgui. It might
be accessed once or twice a month. The user will login and access between
10-50 pages, so it makes sense to use the same process for as many of
those requests as possible, but its not necessary to have the process
running 24/7. I would use the web server's process manager here to shut
down the process after a certain time, and to start it again for a new
request.

- Albert

--
http://www.docunext.com/

Brian.Akins at turner

Oct 30, 2009, 11:27 AM

Post #6 of 6 (204 views)
Permalink

Re: Fastcgi, use something like spawn-fcgi? [In reply to]

On 10/30/09 1:29 PM, "Albert Lash" <albert.lash[at]docunext.com> wrote:

> But in the end, it is awesome for containing memory leaks and
> automatically re-spawning fastcgi processes.

An external process-manager can do the same.

My point was "do we really want/need this complexity inside httpd?"

Also, the config just seems so "clunky" compared to the proxy config.

> In closing, I'll add that I'm greatly appreciative of both Apache and
> mod_fcgid and was thrilled when I learned that mod_fcgid was getting
> merged into the Apache code base.

I was too, but mostly just because mod_fastcgi was horrible in my testing.

--
Brian Akins

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com