I did some tests with get_by_id and results were a lot faster. Forget the result, but all our direct gets must be eventual now whenever it is a relatively static entity.
Must say I have not used it for queries because the nearly omnipresent issue for use (business transactional stuff) is index consistency not speed. One thing I would really like to know about eventual_consistency and indices is the order of the consistency. If entities get updated in series 1, 2, 3, and the index updates get fanned out to the various index tables, will the eventual index updates also be 1,2,3 or will the order change. The docs aren't clear, and I can imagine either approach might apply. Folks might find it very useful to know this because very often I find myself with eventual consistency issues that could be easily worked around if I could rely on the 1,2,3 index updates. Anyway, recommend EVENTUAL definitely for get_by_id -- works for me at least. hth -stevep On Mar 18, 9:27 pm, "Brandon Wirtz" <drak...@digerat.com> wrote: > Changed to > read_policy=db.EVENTUAL_CONSISTENCY > > First pass testing, queries happened 28% faster. > > Not sure what that will translate to in savings since I run Thread safe... > > But we do a Data store read on 15% of page serves, so things should average > about 5% faster. -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
