On Feb 27, 11:44 am, Jorge Vargas <[email protected]> wrote:
> On Fri, Feb 27, 2009 at 11:39 AM, a.fowler <[email protected]> wrote:
>
> >> > 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.
>
> Exactly this will hurts us mid-time, those "not enlighten" managers
> will say, but that thing crawls! lets go back to our perl + CGI
> scripts now that's fast! or they will say lets just pay "Big java
> firm" and "expensive hosting company" 2000 USD/month to get our CMS
> running.
>
>
>
True. It could go either way. They could get convinced to use TG w/
mod_wsgi et. al. , or they could go with BJF (Big Java Firm)
However, as it stands now, the lone TG2 "hero" programmer has no
chance getting anything started at all.
> > It's certainly, possible things have changed with TG2, but with early
> > TG.9/1.0, I was able to set up some simple demo Intranet/internal apps
> > that ran fine (if a tad slow) under CGI. True, they would have have
> > bucked under even a moderate load, but the fact that it "Just Worked"
> > for the simple case on the user's existing server, sparked interest in
> > and willingness to commit further resources to a TG based solution.
> >
> >
> > And remember, I am not suggesting that CGI be the recommended
> > deployment method. Any CGI docs should be plastered with the
> > appropriate warnings, and perhaps optimization tips, but they must
> > exist. :)
>
> just set paster to serve on 0.0.0.0 and your "dev" server is intranet,
> a lot simpler than CGI and a lot faster. paster http is a full real
> server therefore it's even good for production of small sites and
> intranets (many people have this setup that way)
>
>
If IT/MIS lets an independent developer set up his own public
production server, that's great, but this is not the case we are
discussing. :-)
And in the small biz case, while the "newbie admin" has more freedom,
this also now means fussing with the server's startup/runlevel config
files. Given that it's an app process, some sort of heartbeat/memory
leak monitor will also need to be devised.
> > It more political/emotional that purely technical.
>
> > Without an already invested user base, adding mod_wsgi presents a
> > problem for both use cases I mentioned:
>
> > 1) The Corp IT department (or it's consulting firm), will very much
> > want to avoid any changes to the servers that they can be liable for.
> > If they are not already running wsgi for other apps, adding wsgi just
> > on a whim of a single developer, is not likely going to happen.
>
> paster serve + mod_proxy, that is indeed one of the recommended setups
> (not sure if we have docs for it yet)
>
This has the advantage of working with a stock Apache install. But,
again, this is also asking for an independent and persistent process
that requires babysitting.
Not gonna happen.
mod_fastcgi might be workable here, as it is gaining popularity due to
RoR etc. It still not a default Apache option, but at least it has
wide usage across languages/frameworks, and is far more of a "known
quantity" than mod_wsgi.
And, at least this way, Apache is responsible for the spawn/re-spaw of
the Python process.
I think it's critical to realize that CGI (and to an extent FastCGI)
presents a very good, very audience-compatible, abstraction &
demarcation between the administration/configuration of "Server
Functionality" and "Application Logic".
For now, CGI is *only* way TG2 based "Application Logic" can plugged
in to a wide installed-base of unmodified "Server Functionality".
And, as we have discussed, there are many reasonable cases when
someone may want to implement TG2 at the "Application Logic" layer,
but be unwilling/unable to modify the "Server Functionality" layer for
compatibility.
> My problem with CGI is that ones you are able to do that it will be
> very very slow, TG and python in general is not coded to be run as CGI
> as python's start cost itself is a big disadvantage, you can compare
> it to trying to run J2EE on CGI :)
>
> That said I think no one said it wasn't possible we all said it's not
> recommended therefore I don't think it should be documented, if you
> want to go ahead patches are welcome but please put several ..warning:
> notices saying how this is bad. I don't want bad reviews poping around
> the net because someone wanted to run a 1000 hits/second TG app with
> CGI on a 3USD/month shared hosting and blame TG for it :)
>
>
Certainly a reasonable fear.
Of course, some people would say that even bad press is good
advertising. :)
That is why it's essential that users are aware of, and expecting, the
poor CGI performance.
I don't considere myself knowledgeable enough to write authoritative
docs, but I would be wiling to help review/test them.
Though, perhaps I can write a provisional "configuration guide" as I
document an attempt to get CGI working with TG2.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
