Re: Smolt deployment

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

Attachment: signature.asc
Description: This is a digitally signed message part


[Index of Archives]     [Fedora Development]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]

  Powered by Linux