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



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

Reply via email to