Hi Tim, On Sat, Apr 17, 2010 at 7:27 PM, Tim Hoffman <zutes...@gmail.com> wrote: > HI Darryl > > Here's a couple of quick tips and these where a big win for us. > > 1. Memcache page output heavily, and if possible serve the pages > without even starting up or initialising bfg. > We found we could do a cold startup and serve a page from cache in > 200ms cached page from memcache in 30ms. In this scenario you don't > want to import any thirdparty libraries, just use what comes out of > the box from appengine. ( ie importing any module not part of the > core gae env always seems to take longer.) Whereas just starting bfg > before doing anything could take between 3-4 sec and on a bad day a > lot longer. Then if its not in the cache start bfg and process the > page request. > > 2. Defer loading/importing stuff where possible. For instance we use > formish/schemaish for forms. But if no one is logged in > then we don't need to do the formish/schema imports. If someone is > logged in then we do import formish. That way we only incur import > costs when we actually use things. This is hard to control with zcml > and a lot easier to do if you are directly registering things in > python. Also it means you don't have the cost of parsing zcml as > well.
Thanks a million for sharing! Very best, Darryl > > Rgds > > T > > > > On Sat, Apr 17, 2010 at 3:52 AM, Darryl Cousins > <darryljcous...@gmail.com> wrote: >> Hi Tim, >> >> On Thu, Apr 15, 2010 at 1:55 PM, Tim Hoffman <zutes...@gmail.com> wrote: >>> Hi Iain >>> >>> I have a number of projects on app engine. Some using repoze.bfg >>> (www.polytechnic.wa.edu.au (paid work), www.fishandlily.com.au (my >>> small business)) and others just using zope.component and bobo (not >>> public yet). >>> >>> We are using app engines persistence model which is simple and >>> straight forward. (http://code.google.com/p/bfg-pages/ has some >>> examples of implementing a very simple cms on bfg and appengine, it >>> implements traversal over entities in the datastore as folders and >>> content). >>> >>> I think bfg is a good fit with appengine. A couple of pointers, you >>> are basically using the view, traversal, component registry >>> mechanisms and not zodb/persistence (which isn't really core to bfg). >>> We are not currently using chameleon but straight zpt with a custom >>> bindings see the link above. You need to watch startup times so I am >>> moving away from using zcml and using python to register things. >> >> Yes, start up time is something I've noticed too. Aside from not using >> zcml for component registration do you have any other pointers to help >> with that problem? >> >> Thanks in advance, >> Darryl Cousins >> >>> >>> The really big advantage of app engine as I see it, is not having to >>> deal with the system platform (ie cpu's disk, memory, networks, etc..) >>> app engine is purely a runtime and services. So if you have little in >>> the way of IT admin support, it is a big win. >>> You do have to make some concessions/design compromises to take into >>> account the restrictions enforced by the platform. >>> >>> As for economics www.polytechnic.wa.edu.au gets about 7000 unique >>> visitors a day, around 20,000-50,000 page views a day and >>> we have billing enabled but rarely get over 50% of the free quota so >>> it's currently not costing anything at the moment to run. >>> >>> Rgds >>> >>> T >>> >>> >>> On Thu, Apr 15, 2010 at 7:46 AM, Iain Duncan <iainduncanli...@gmail.com> >>> wrote: >>>> Hey all, I have an app that eventually is intended to be used as a >>>> subscriber service. I'm totally new to the cloud thing, wondering if >>>> experienced bfg'ers would like to weigh in with their experiences >>>> - what is your preferred cloud deployment for bfg apps? >>>> - what persistence mechanism gets used? Is there some kind of facade over >>>> the bigtable? How do you handle it? >>>> - what is your experience with using cloud deployment, do you think it's >>>> even worth it? >>>> thanks! >>>> Iain >>>> _______________________________________________ >>>> Repoze-dev mailing list >>>> Repoze-dev@lists.repoze.org >>>> http://lists.repoze.org/listinfo/repoze-dev >>>> >>>> >>> _______________________________________________ >>> Repoze-dev mailing list >>> Repoze-dev@lists.repoze.org >>> http://lists.repoze.org/listinfo/repoze-dev >>> >> > _______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev