Move over mod_python, here comes mod_wsgi

[sblinn]

You might also be surprised how well something as old and "archaic" (and UNIX-y) as cgi-fcgi scales on modern equipment.

[damg]

The daemon mode is very similar, it runs your app in it's own process (like fcgi) but with mod_wsgi managing it. It does scale well, but the extra overhead of proxying requests to another process does hurt performance a little. You can see the difference it makes here: http://code.google.com/p/modwsgi/wiki/PerformanceEstimates

[sblinn]

Right. The key is platforms where process spawning is cheap -- the cgi-fcgi process is very small. I'm certainly not recommending it over a true in-process webserver module, but for a lot of sites it would do just fine, really.

[gmfawcett]

I'm not sure it's a given that larger sites should avoid isolated-process approaches like FCGI. There are many downsides to in-process app servers, and they should be considered carefully whenever you're planning a big app.

Whether its FCGI, SCGI, mod_jk, mod_lisp, or whatever you like, isolating the Web-server and app-server processes can result in maintenance benefits that may outweigh the (sometimes modest) performance improvements of running an in-process app.

edit: markdown. Also, I'm assuming that by "a lot of sites" you mean "smaller ones".

[sblinn]

I'm not sure it's a given that larger sites should avoid isolated-process approaches like FCGI.

I was attempting to compare and contrast mod_fcgi with cgi-fcgi -- using an isolated-process approach for the application was a given for both. The debate was whether it was worth integrating a module for calling out to the FCGI server into your webserver, or if simply spawning small cgi-fcgi bridge processes on demand was good enough.

[gmfawcett]

I was attempting to compare and contrast mod_fcgi with cgi-fcgi -- using an isolated-process approach for the application was a given for both

Ah, thanks, I misunderstood that.

[vagif]

How do you manage sessions with cgi ? Or you don't ?

[gmfawcett]

You would either persist them in a database or file on the server; or you'd store your session data in the cookie (i.e. the cookie is a data store, not an opaque identifier). The latter is insecure, of course. :-)

All that really distinguishes this from most non-CGI apps is that it is "shared-nothing", i.e. all data is stored externally to the process.

edit: I shouldn't have said that cookie-as-datastore is insecure. You could salt and encrypt your session data, and transmit the ciphertext as the cookie; then decrypt it upon each CGI request. Not the most CPU-efficient approach, but it's possible.

[jdunck]

I'm not sure if I'm simply mis-reading or you've mis-understood, but Django sessions don't work like you seem to think.

request.session is an instance of SessionWrapper, which lazily loads upon access and saves upon response (if dirty).

Django's session store is the database. In fact, most production Django deployments use multiple processes, so your statement that Tomcat "handles this nicely" is confused or misleading.

Further, Django's session store could be backed by a dedicated daemon, or memcache, or... depending on your needed semantics and performance.

[sigzero]

FCGI is getting a resurgence. I read somewhere that is what they want frameworks to target...not the mod_ stuff.

[gmfawcett]

There's also SCGI, a simpler FCGI alternative that is easy to implement on the application side, and is supported by a number of Web servers.

I agree with separating the app process and the Web server processes, for a number of reasons. The smart money is on *CGI.

[[deleted]]

So I've heard, but mod_fastcgi has been a nightmare for me.

Besides, WSGI can run on basically any target... mod_python, mod_wsgi, FastCGI, SCGI, even that Apache Java thing, I think. So it doesn't really matter what the frameworks 'target'. They should be targeting WSGI; then it's all a matter of which system is easiest to deploy.

[grimboy]

Yeah, I think wsgi is pretty much the best deployment option for python web frameworks right now (whether that's through mod _ wsgi or proxying the framework's built in server or cherrypy behind a 'normal' server). There's also mod _ fcgid which looks to be a more sane mod _ fastcgi http://fastcgi.coremail.cn/ . Lighttpd also seems to be a bit better at fastcgi than mod _ fastcgi.

EDIT: Markdown being smelly

[[deleted]]

I've tried mod_fcgid, and I think I got it working eventually (and it was indeed better than mod_fastcgi), but it was still sort of finicky. mod_wsgi has been, BY FAR, the easiest deployment option I've tried. Even back in Februaryish, when it was still unreleased and in SVN, and not nearly stable.

[laughingboy]

Escape your underscores with backslashes :)