Smolt deployment
Toshio Kuratomi
a.badger at gmail.com
Sun Mar 4 05:20:15 UTC 2007
On Sat, 2007-03-03 at 17:31 -0500, seth vidal wrote:
> On Sat, 2007-03-03 at 11:20 -0800, Toshio Kuratomi wrote:
> > On Sat, 2007-03-03 at 11:43 -0600, Mike McGrath wrote:
> > > This is mostly for the TurboGears guys in the group. We've discussed
> > > this a little in the past but I wanted to get something down for sure
> > > before all of our stuff goes live. Whats going to be our official
> > > deployment method? Personally I'd vote mod_python though I haven't
> > > actually done this yet. Does using mod_python still require a proxypass
> > > to a tg port? I'd tend towards mod_python just because it would behave
> > > just like the rest of our apps do though I know toshio has some neat
> > > script that makes it behave that way too. What do you guys think?
> > > mod_python may be too complex for what we're trying to accomplish.
> >
> > Just some random thoughts as I'm running out the door:
> >
> > I have never gotten mod_python to work with a cherrypy/tg based
> > application by following the documentation on either project's wikis.
> > That said, I haven't tried with TG since 0.8 so perhaps the process (or
> > just the documentation) is better now.
> >
> > I like the way I'm doing it because I've got it to a state where it
> > pretty much just works but if we can do that with mod_python as well,
> > that would be fine. My method is basically Apache proxypassing to the
> > turbogears application server. If the tg server isn't running, the
> > proxypass error handler loads a small cgi script that starts the
> > turbogears app and once the app responds, sends the user there.
> >
> > TurboGears is trying to become more WSGI compliant. TG-1.1 is supposed
> > to use cherrypy-3.0 which has a builtin mod_python->WSGI gateway. That
> > should make mod_python deployment simpler than with cherrypy-2.2.
> >
> > So I think -- if we can make mod_python easy to deploy, that seems the
> > way to go. If we can't then I've got something that will work until
> > TG-1.1 and a more integrated WSGI implementation.
> >
> > Tangentially: We probably want to preserve the ability to run our apps
> > on several different servers. Because python libraries don't do
> > versioning (well -- we may be able to do it with setuptools and eggs,
> > but that's a long term, distro-wide change.) we can enter situations
> > where some web apps depend on TG-1.0 and others on TG-1.1 (or sqlobject
> > or python-urlgrabber or...) Being able to proxy to a xen host during
> > transition periods rather than having to upgrade all our web apps at
> > once is probably a good thing.
>
> How performant is the tg server? In the past the python webserver was
> not exactly a barn burner when it came to performance. It worked, but it
> didn't hold up well under heavy load. Having apache in front helps but
> just like with zope, if the app is slow, the app is slow.
>
> any load testing done, yet?
There are some benchmarks for cherrpy-2.0 (TG-1.0 uses cherrypy2.2,
TG-1.1 will use cherrypy-3.0)
http://www.cherrypy.org/wiki/CherryPySpeed
http://docs.cherrypy.org/recommended-setup-for-production-websites
Gives some stats for page requests from behind apache vs having the
cherrypy server directly exposed.
http://www.cherrypy.org/wiki/WhatsNewIn30
Says that cherrypy3 is "as much as three times faster in benchmarks" as
cherrypy2 but I haven't seen the benchmarks.
-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-infrastructure-list/attachments/20070303/7de89b0a/attachment.sig>
More information about the Fedora-infrastructure-list
mailing list