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. 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
