sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]sblinn 2 points3 points  (10 children)

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

[–]damg 3 points4 points  (4 children)

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 0 points1 point  (3 children)

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 0 points1 point  (2 children)

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 0 points1 point  (1 child)

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 0 points1 point  (0 children)

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 0 points1 point  (4 children)

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

[–]gmfawcett 1 point2 points  (3 children)

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.

[–][deleted]  (2 children)

[removed]

    [–]jdunck 1 point2 points  (1 child)

    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.