On Feb 23, 9:46 am, "a.fowler" <[email protected]> wrote:
> > > Although, this may not be the best deployment method, there should be
> > > a well written section on how to deploy via plain CGI. (This is the
> > > lowest common denominator on shared production servers )
>
> > To be honest I'll prefer to get people away form CGI, to the point of
> > making it undocumented.
>
> No. Bad move. CGI via WSGI must be well documented. (With added
> advice to use other methods, certainly.)
Have you ever actually looked properly at the startup cost of a TG
application, it is quite significant and sometimes far from being sub
second. By using CGI you would get quite dreadful performance as every
request has to load the whole framework. This loading on every request
would severely impact the performance of the machine, so much so that
an admin is likely to tell you to stop it, if it is a shared resource.
It is for this reason that one shouldn't be using CGI and why it
shouldn't be recommended.
> Why?
>
> Because in several major target markets for low-volume TG use, the
> developer does not have an authoritative final say on deployment
> server configuration.
>
> Case #1 : Corporate Intranet deployment
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> No corporate IT admin will allow a department-wide, or company-wide,
> application to be deployed on a developer's private "homebrew"
> server. Never gonna happen. No way.
>
> Further, IT departments are notoriously loathe to add runtime support
> for the latest wiz-bang framework that some newly-hired departmental
> developer wants to use.
>
> But, a request to deploy a low volume app via Pyhon/CGI would likely
> be granted. A request for the production server's Apache to be
> reconfigured withmod_wsgi... less likely.
>
> Now, once the slick new application is being used and liked by other
> employees, a request to redeploy undermod_wsgi/mod_proxy would be far
> more likely to succeed.
>
> Case #2 : Small biz Intranet
> ~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Here, there may be no "IT department". The "developer" may in fact
> be a regular employee with other responsibilities.
>
> The "developer" needs a simple way to deploy an application on a
> "server". So he/she takes an old workstation and loads CentOS/Ubuntu
> Server with a GUI installer.
>
> Out of the box it's configured with Apache and CGI support. (And,
> ahem, PHP...)
>
> Now, how much more mucking around is required to get the application
> safely deployed?
>
> standalone mode: Fussing with server autorun files, and making a
> heartbeat monitor to restart crashed apps.
>
> mod_wsgi: Better, but still installing apache module, and non-trivial
> server config file editing.
>
> cgi: Just works. Perhaps with some basic .htaccess edits to use
> mod_rewrite for nicer URLs
Hmmm, are you saying mod_wsgi is non-trivial to setup just on
principal or you have some reasoning to back that up.
Once mod_wsgi is installed into Apache and LoadModule line added,
actually configuration a WSGI application is no more difficult that a
CGI script. This is because both work of a file based resource as
entry point, unlike the bodgy way that mod_python works.
Maybe you should review:
http://code.google.com/p/modwsgi/wiki/ConfigurationGuidelines
If you replace WSGIScriptAlias with ScriptAlias and wsgi-script with
cgi-script, you would end up with exactly what you need to do for CGI
anyway.
The only extra work in mod_wsgi comes from it being preferable that
daemon mode be used.
Daemon mode is preferred because most people aren't adept at Apache
and don't even seem to understand the need to choose correct MPM and
then tune its settings for type of application being run. It is also
more often than not the case that if running a fat Python web
application that you want to dedicate the server to it. That is, don't
try and run PHP, or even perhaps static files at the same time, as the
MPM settings required for each are quite different.
Graham
> Again, as usage grows, better options can be explored.
>
> Case #3 : small website
> ~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> A neighborhood business or non-profit has a "web hosting account" at
> any of the commodity web hosts, and wants to add some dynamic content
> to their website.
>
> Again, without an "IT Department" upgrading to even a cheap "virtual
> private server" just ain't going to happen.
>
> Thanks to the success of Ruby-on-Rails, FastCGI support is now fairly
> common.
>
> TurboGears has a chance here if the user can figure out CGI (and
> eventually FastCGI) deployment.
>
>
>
> > > After that, a section on FastCGI, followed bymod_wsgi, etc.
>
> > Did you misshttp://www.turbogears.org/2.0/docs/main/Deployment.html
>
> Yes, I saw it. That is what prompted my comment. :)
>
> (BTW, it has some broken links...)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---
