Slashdot Mirror

mod_fastcgi doesn't support multiplexing either. Why would you make an incorrect comment when you can just Google something simple like this?

http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html

"The FastCGI protocol supports a feature, described in the specificiation as "multiplexing", that allows a single client-server connection to be simultaneously shared by multiple requests. This is not supported."

You seem to be confusing multiplexing with persistent connections, which mod_fastcgi and mod_fgcid certainly do support. Since you're such buddies with Google, I'm sure you're aware that the entire point of FastCGI is to avoid having to create a new application or script process and connection to it for every HTTP request. These persistent processes and connections are what both mod_fastcgi and mod_fcgid make easy and if nginx cannot do the same, it is not a good replacement. Why would you make an incorrect comment when you can just Google something simple like this?

mod_fastcgi doesn't support multiplexing either. Why would you make an incorrect comment when you can just Google something simple like this?

http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html

"The FastCGI protocol supports a feature, described in the specificiation as "multiplexing", that allows a single client-server connection to be simultaneously shared by multiple requests. This is not supported."

http://www.fastcgi.com/

Sure, but how's that relevant now? There are FCGI implementations that are ready to use. FCGI seem to be maintained right now. So what makes FCGI a bad choice *today*?

FastCGI is over-complex and was abandoned tech until the rails guys started using it. mod_${script_host} was deemed a better solution by almost everybody back in the day.

Compare the specs: SCGI FCGI

You could probably write a SCGI daemon in your lunch hour.

It looks like there are 3 choices for running Rails on Apache2:

mod_fcgi - original fastcgi, been 18+ months since last code change
http://www.fastcgi.com/

mod_fcgid - binary-compatible with fastcgi with improved process management
http://fastcgi.coremail.cn/index.htm

mod_scgi - simpler protocol utilizing Python (not sure of speed vs other two)
http://www.mems-exchange.org/software/scgi/

Which do you use and why? Are there any comparisons that show both speed and memory utilization among these? Did you try one and dump it after finding problems?

If you need scripts to run as different users then just use suEXEC (http://httpd.apache.org/docs/2.0/suexec.html), which is designed for that very purpose (and comes standard with Apache). One problem with this approach, however, is that you will experience a performance penalty because suEXEC only works for CGI scripts.

If you need to have the speed of a module together with the security of suEXEC then you need to install the FastCGI module too. FastCGI (http://www.fastcgi.com/ is a communication protocol that allows scripts to remain persistent and process more than one request from a single process. (And, yes, FastCGI is smart enough to only create processes when they are needed and to shut them down when they are not needed any more.) The thread-safety problem would also go away.

It supports FastCGI so pretty much any webserver that has support for FCGI should work. lighttpd is my personal favorite (much less bloated than Apache). IIS has a FastCGI ISAPI plugin so IIS should be fairly easy.

The basic idea is that the web server starts up some CGI program, lets it do all its initialization, and lets it run to the point that it is ready to accept data for a specific transaction. Then it makes a call to wait for transaction data. When a transaction comes in, the server forks off a new copy of the initialized transaction program. That copy deals with one user transaction, and then exits.

Congratulations - you've just invented FastCGI. At least, you would have done if you'd come along a decade or so ago (its been around at least since 1996).

And yes, its available for use with C, Perl, Python and Java - oh, and Smalltalk, Lisp, Ruby, VMS, and others as well. You can even get supported plug-ins for the more common webservers.

Alright, so you specify a forced fork rather than an optional one. Still, that's a pretty trivial difference.

User directive
Special note: Use of this directive in <VirtualHost> requires a properly configured suEXEC wrapper. When used inside a in this manner, only the user that CGIs are run as is affected . Non-CGI requests are still processed with the user specified in the main User directive.

Hey, web stuff is easy with Ruby as well. But I don't have such examples for you.

I have:

• Instiki, a Wiki completely written in Ruby. Has Revisioning Support, Internationalization, Feeds, Exporting to HTML and Latex, multiple Markup engines and more. I think the work on it started like three months ago.
• ActiveRecord: It is a object-relation mapping layer for Ruby. Just have a look at how natural it feels to use it and you will see what Ruby is able to do for you.

There's more like web engines that use Continuations to create a sequential application metapher, great templating engines and even multiple ways of making Ruby very performant in Web Applications.

I was just reading about that dillemma here:

http://otn.oracle.com/oramag/oracle/02-nov/o62odev _java.html

If you ask me, the whole thing is retarded. Whenever you get these high level abstract frameworks, they imply limitation and slowness, both in running and writing. (Examine Zope as a perfect non-java example.) People forget that learning new frameworks takes lots of time, time that could have been spent just writing code. They also limit what you can do for everything they give half the time.
I used to use j2ee on tomcat, but I found that for many projects the faster to write faster to run solution was via fastcgi.
http://www.fastcgi.com
The principle in my sig seems to hold true the better I get.

If you're interested in what the Slashdot effect looks like for a relatively small story, look here: http://www.shacknews.com/docs/amd.x BTW, that spike at 4am is the nightly backup. The webserver load jumped, but the database server was fine since it is run through FastCGI

You never heard of mod_perl, FastCGI, Embperl, or the Template Toolkit if you're still talking about PERL CGI scripts, have you?

Apache and PERL is still the bleeding edge of web developement. It's just no more alone at the top. Perhaps you should take a look on these Benchmarks. Especially the JSP don't look very good there and Embperl2 is usually very close to PHP regarding performance. Only Apache modules written in C are without real competitor. But you should also think about the ease of developent if you compare C code with PERL, PHP, ASP or JSP.

A CGI written in C is almost certainly vastly slower than simiar code writen as a Java servlet. Deal with it.

Unless you use FastCGI (supported by Apache with mod_fastcgi)... an extension to the CGI spec that, amongst other things, allows persistent processes. Being a simple extension to CGI, it's also completely language-agnostic and cares not whether you use threading, or, for the real gurus and speed demons, asynchronous programming.

Of course, if you want to lock yourself in to a vendor-controlled, language-specific server-side architecture, that's your business. Why limit yourself though?

A CGI written in C is almost certainly vastly slower than simiar code writen as a Java servlet. Deal with it.

Unless you use FastCGI (supported by Apache with mod_fastcgi)... an extension to the CGI spec that, amongst other things, allows persistent processes. Being a simple extension to CGI, it's also completely language-agnostic and cares not whether you use threading, or, for the real gurus and speed demons, asynchronous programming.

Of course, if you want to lock yourself in to a vendor-controlled, language-specific server-side architecture, that's your business. Why limit yourself though?

FCGI is basically using C as a CGI scripting language library with additional C support libraries available for doing stuff which is hard in C (such as HTML output functions and text parsing and stuff). it simply replaces perl (and mod_perl) with C (and mod_fcgi). its open source and stuff. check out : http://www.fastcgi.com/docs/faq.html#c_cgi_libs

for all those here not old enough to remember the birth of the world wide web and scripting languages for generating dynamic html for web servers, perl was NOT the first scripting language or the fastest. C with FastCGI was the first and it blew away everything in terms of speed (near assembly performance over the web, bare metal -- yeah) but like C's in the usual case it was a bitch to develop dynamic web stuff when perl could do it easier (although slower). so everyone switched to perl and the rest is history (ignoring the flames that went on and ppl whining about perl being really slow).

of course now everyone is switching to java which is even slower but even easier to develop for so history will probably repeat itself again. we already have the java flaming well underway...

The way to create the best application possible is to take a langauge you know well, and use it. Period. Suddenly going and studying "Language X" because you think it might be best for a client while doing work for said client likely will create a lot of headaches and long hours for everyone involved. If you find out in the end that it wasn't the langauge you should have used for the project, you're screwed.

Optimize the code you know how to optimize, and use (properly coded) external tools to handle requests you can't handle well on your own. Breaking up large programs into a series of smaller ones is acceptable; look at KDE. One tool that I am surprised does not get more publicity is FastCGI. It is the only langauge and web server independant (more or less) way I have found to speed up CGI scripts. Perl scripts coded for mod_perl more or less port easily to FastCGI, with most of the performance boost. And here's the real kicker; unlike mod_perl or PHP, which take up huge chunks of memory, mod_fastcgi for Apache does not. A small handler simply hands off control to one or more copies of your program running on the side, possibly even on another server!

I've used FastCGI extensively on systems that otherwise could not serve the load they had to handle. While it is not used as much as mod_perl or PHP (it no longer is in the core Apache distribution because it evolved too rapidly), I strongly encourage people to consider it a choice.

Isn't this one of the things FastCgi is supposed to be fixing, instead of launching one process per perl script, it launched one perl interpeteror and passes it all the perl scripts, hence less overhead, and more speed (with the drawback that the scripts have to explicitly free memory and be slightly modified) (with a loop about the script)

Not quite thread like, but definitly not on process per cgi request.

--