FastCGI vs. Simple CGI

I’ve seen several postings where FastCGI is being used with RoR
projects, yet, most of the material I’ve read (Dave T.’ book, online
articles, etc) recommend not using FastCGI anymore because it is a
dormant project and hasn’t been updated since 2003 (I think???).

So, I went out and got Simple CGI instead. It had to be compiled and
installed from source on my Suse boxes, but it works just fine and had
the advantage of also working just fine on my XP notebook.

Is there a reason folks are using FastCGI over Simple CGI?

Hello Cody…

From what I understand its related to when SCGI became production ready
which was only few months ago…

I have feeling that ASF’s renewed interest in the mod-fcgi code that
people will be using both for awhie with big improvements in obht as
they competee with another…

But like You I am choosing SCGI although I still pratice deploying to
both to keep my knowledge of both current…

Cody S. wrote:

I’ve seen several postings where FastCGI is being used with RoR
projects, yet, most of the material I’ve read (Dave T.’ book, online
articles, etc) recommend not using FastCGI anymore because it is a
dormant project and hasn’t been updated since 2003 (I think???).

So, I went out and got Simple CGI instead. It had to be compiled and
installed from source on my Suse boxes, but it works just fine and had
the advantage of also working just fine on my XP notebook.

Is there a reason folks are using FastCGI over Simple CGI?

Cody S. wrote:

I’ve seen several postings where FastCGI is being used with RoR
projects, yet, most of the material I’ve read (Dave T.’ book, online
articles, etc) recommend not using FastCGI anymore because it is a
dormant project and hasn’t been updated since 2003 (I think???).

I’d be careful not to confuse the Apache mod_fcgi module (which was
dormant at
the time the AWD book was published, I think this has changed some
recently)
with the FastCGI module that comes as part of LightTPD. IMO, LightTPD is
the
premier production deployment solution for Rails apps, today.

Obviously, that could change in the future, but I’ve been using it for
the past
6 months and it’s been outstanding for deploying my Rails apps under OS
X Server
(but should work equally well for any *nix system).

So, I went out and got Simple CGI instead. It had to be compiled and
installed from source on my Suse boxes, but it works just fine and had
the advantage of also working just fine on my XP notebook.

Is there a reason folks are using FastCGI over Simple CGI?

With FastCGI behind LightTPD, there’s a compiled Ruby module that works
really
well. I also believe it makes things faster, overall, and more memory
efficient.
This is not the case with SCGI. The Ruby SCGI Runner, by Zed S., is
normal
Ruby code, which is less efficient for Unix-based systems. I don’t
really know
the situation for Windows-based deployment, since that’s not something
I’ve ever
had to look into…

-Brian

I don’t use lighttpd personally, but several people have downgraded
from 1.4.10 to 1.4.9 and reported that it’s a stable setup.
Apparently 1.4.10 is a “bad” release, but 1.4.9 was “good” (from a
Rails perspective).

Search the mailing list archives for details

Regards

Dave M.

I’m using SCGI behind Apache on windows, and used memcached demand on
linux
server, but i do not know how much the memory efficient.

2006/3/3, Brian V. Hughes [email protected]:

recently)

So, I went out and got Simple CGI instead. It had to be compiled and
normal
http://lists.rubyonrails.org/mailman/listinfo/rails


Best Regards,

Caiwangqin
http://www.uuzone.com
Mobile: +8613951787088
Tel: +86025-84818086 ext 233
Fax: +86025-84814993

Brian V. Hughes wrote:

I’d be careful not to confuse the Apache mod_fcgi module (which was
dormant at the time the AWD book was published, I think this has
changed some recently) with the FastCGI module that comes as part
of LightTPD. IMO, LightTPD is the premier production deployment
solution for Rails apps, today.

In response to: “I’d be careful not to confuse the Apache mod_fcgi
module (which was dormant at the time the AWD book was published,”…

There is no Apache module named “mod_fcgi”. There are 2 released
FastCGI modules for Apache and one that is upcoming:

  • mod_fastcgi for Apache 1.x/2.0 - version 2.4.2 released in Nov 2003
    and last snapshot distribution is April 2004.

  • mod_fcgid for Apache 2.x - version 1.08 released in Jan 2006 and has
    always been actively maintained (so this cannot be the dormant
    “mod_fcgi” you mentioned).

  • mod_proxy_fcgi for Apache which is new and not even released yet

In response to: "IMO, LightTPD is the premier production deployment

solution for Rails apps, today"…

I’ve been using Lighttpd on an internal test server and I can say that
Lighttpd-1.4.10 (latest stable version) is not as stable as Apache.
Lighttpd-1.4.10 has massive memory leaks and other stability problems
which are well-documented at:

In terms of performance, people should be aware that benchmark
comparison between Lighttpd and Apache 2 is with MPM-Prefork. Note that
Apache’s MPM-Prefork makes Apache 2 perform as badly as Apache 1. One
reason someone might use MPM-Prefork for benchmarking Apache 2.x is to
make sure they have the slowest possible performance to make their
product shine. If you look at the source of the benchmark, it is a
commercial webserver vendor trying to emphasize their performance
advantage.

To avoid getting fooled, I encourage you to do your own benchmarks
instead of falling victom to hype. Use ab or seige on a separate
physical machine to benchmark your server software. You’ll see results
vastly different from biased benchmarks posted online by people trying
to push their products on the public.

One last issue to consider is that Lighttpd does not (yet) have
mod_security which can prevent XSS and SQL injection attacks and more.

Given the stability/memory-leak problems, lack of compelling speed
advantage over Apache 2 MPM-Worker, and lack of mod_security, I really
don’t see how Lighttpd can be considered the “premier production
deployment solution for Rails apps, today.”

Believe me, I’d be one of the first to use Lighttpd in production if it
performed better than Apache 2 but it just isn’t ready for prime-time
yet. In the meantime, I’ve submitted several Lighttpd bug reports and
suggested the use of splint (which the author said he’d investigate) so
I’m doing my part to help Lighttpd catch up to Apache’s robustness. The
worst we can do is pretend it is better or even on par with Apache today
by ignoring reality.

Is it still true that with SCGI and Apache, you can only have a single
handler since mod_scgi isn¹t smart enough to split the load? That was a
killer for us with Apache+SCGI (lighty doesn¹t have this problem).

From: Jesse C. [email protected]
Reply-To: [email protected]
Date: Fri, 3 Mar 2006 10:21:00 +0800
To: [email protected]
Subject: Re: [Rails] FastCGI vs. Simple CGI

I’m using SCGI behind Apache on windows, and used memcached demand on
linux
server, but i do not know how much the memory efficient.

Rich A. wrote:

For now, I think it is more prudent to run Apache 2.0.55 with mod_fcgid
and mod_security.

Thanks to everyone for responding. This information will change the
direction I’m headed in.

Rich A. wrote:

Dave M.

  • #552 CGI process zombies if request isn’t read
    Also, if the only reason you’re using Lighttpd is because you were led
    to believe it is much faster than Apache 2.x, then do your own benchmark
    using Apache 2.0.55 MPM-Worker (not MPM-Prefork)–be sure to be sitting
    down before reading the results because you’ll be surprised at which is
    faster.

Have you published your preferred configuration of Apache
2.0.55/MPM-Worker/mod_fcgid/Rails?

It sounds as if this would be extremely useful to people working in
corporate environments with tight controls on infrastructure,
particularly where the chosen server platform is Windows.

thanks very much for the advice

Justin

David M. wrote:

I don’t use lighttpd personally, but several people have downgraded
from 1.4.10 to 1.4.9 and reported that it’s a stable setup.
Apparently 1.4.10 is a “bad” release, but 1.4.9 was “good” (from a
Rails perspective).

Search the mailing list archives for details

Regards

Dave M.

A patched version of Lighttpd-1.4.10 is working more reliably for me
than 1.4.9. I hope more people would give Lighttpd-1.4.10+ in svn a try
so that 1.4.11 can be the most stable release ever.

If using the latest from svn, be aware that the changes in revision 1009
are incomplete for mod_fastcgi.c and mod_scgi.c. The change to those
files need to happen in 2 places but was only done once.

And if using the old Lighttpd-1.4.9, be aware of these issues:

  • #203 virtual hosting (evhost) domains are not case insensitive
  • #470 mod_cgi is not accepting valid responses
  • #480 mod_fastcgi is only using 1 fastcgi-host for load-balancing
  • #492 False Content-Length on some 30x redirects
  • #493 server.modules is unpopulated on startup
  • #495 can’t use $HTTP[“remoteip”] inside $HTTP[“url”]
  • #502 mod_ssi ignores assigned mime type
  • #505 Complete header variable matching
  • #509 rejects IPv4 connects with server.use-ipv6
  • #510 allows one connection, then shuts down
  • #552 CGI process zombies if request isn’t read
  • #554 Fix for CGI / Zombie issue in ticket # 552

For now, I think it is more prudent to run Apache 2.0.55 with mod_fcgid
and mod_security.

But I’m very optimistic that Lighttpd will finally become ready for
prime-time this summer (or even sooner). By “prime-time”, I mean stable
& secure enough to run ecommerce websites that people can use for their
sole income.

Also, if the only reason you’re using Lighttpd is because you were led
to believe it is much faster than Apache 2.x, then do your own benchmark
using Apache 2.0.55 MPM-Worker (not MPM-Prefork)–be sure to be sitting
down before reading the results because you’ll be surprised at which is
faster.