FastCGI: the way ahead?
I picked up an article about FastCGI, SCGI, and Apache by Mark Mayo.
I found interesting and insightful, but some of the conclusions or opinions diverge from my own, enough to make me write them down.
First, let me say that I'm sure I don't have as much experience as Mark with FastCGI, and none with SCGI. I do have 5 or 6 years experience with mod_perl. Also, I've recently switched from Apache to Lighttpd due to the lack of a good FastCGI implementation on Apache (something that is probably going to change).
I do agree with Mark on most issues:
- FastCGI has been considered abandoned technology for quite some time;
- The new frameworks require some sort of application server-mode to avoid being reloaded per request;
- We need a protocol to communicate between the front-end web server, and the application instances, running in a different process space;
- mod_p* is a memory hog, been there done that. Also security-wyse, not that good;
- mod_* are not a viable way forward. Mark's reasons are very good on that one, and cover most of my issues with them.
One particular sentence summarizes our common ground:
A generic solution for persistent out-of-process page generation/handling is needed
But then the question arises: should we continue with [FS]CGI and friends or use basic HTTP between the front-end web server and the back-end application servers? Zope and Java app servers went the HTTP route, for example.
Here we start to diverge. Mark seems to think that HTTP is the way forward. I don't. I don't know if FastCGI or SCGI are the way forward, not yet, too little time with the technology, but I feel that using HTTP is the wrong way to do it. I feel we need a simple protocol, and push the server-side implementation of that protocol to current web servers. That way, we can reuse all the HTTP stack and all the code to manage multiple child process already inside most web servers today.
Let me try and tackle the several points made for using HTTP.
Configuration must be simple. Yes, it must. But what is more simple than what the sysadmin already knows? He's been living with Apache (or his own other web server) for last few years now, so configuring a couple of parameters about where the application is and number of instances to start should be trivial for him.
If you need to isolate your app servers on some sort of jail that makes starting the instances from the main front-end web server impossible, then use the same server, Apache for example, inside the jail as a instance manager, and use tried and true mod_proxy from the first set of front-end web servers to the second set.
Bottom line, my answer to Marks question 'why the current darlings havenât also taken the same approach' is to point out the beginning of the previous paragraph (emphasis mine):
What Java and Zope app servers do (for the unfamiliar) is run their own solid HTTP servers
Writing a solid HTTP server is not easy. and more its no longer required, and that's the reason we should use a simpler protocol, and leave all the decisions of dealing with simultaneous requests and multiplexing several instances of the app to already existing and tested code.
The point is we don't need another HTTP stack or another application server, we already have a good one in Apache or Zeus or lighhtp. Let's not rewrite an Apache on each MVC framework.
Thanks for a great article, Mark.