If you enable eventually consistent queries, a batch get by key in high replication should perform as fast as in master/slave.
The practice you're citing from Brett is a few years old and predates high replication; would you be willing to revisit it if I roped him into updating it for high replication? -- Ikai Lan Developer Programs Engineer, Google App Engine plus.ikailan.com | twitter.com/ikai On Thu, Aug 18, 2011 at 2:58 PM, thstart <[email protected]> wrote: > +Joshua Smith > >From my reading, M/S seems to have better throughput than HR, at the > expense of more frequent downtime, > >and spurious datastore timeouts. I'd like to have that option in a > multi-threaded app. > > This is more important for public app (site) with many anonymous users. > > My app is 100% user based - e.g. used after log-in, but heavy on data > related to each particular user. > The users are not accessing it very often (say they access it many times a > day but this is not much) > but when they access it they need to be as fast as possible. > > So *frequent downtime *is a non-issue, the chance a user to access it at > exactly this time are minimal,* * > *spurious datastore timeouts *is a non-issue because this is rare - so I > can live with Master / Slave > imperfections - it is good enough and I don;t need to rewrite and optimize > again. > > +Ikai Lan > >Master/Slave doesn't have better throughput. In the 99th percentile, > because of datastore latency spikes, > >high replication far outperforms master/slave. > > I think Master/Slave is a lot faster in my case up to 10 times faster. I > tested it with only read, no write operations, > no transactions, nothing special for example I have a heavy use of this > expression: > > * > e = MyList.get_profile(email) > * > * > my_keys = e.my_keys > my_members = db.get(my_keys) > > for member in my_members: > member.<property>, etc. <-- do something with the > property > > * > *and it is parallel in Master/Slave (according to Brett Slatkin > presentation) . In High Replication I believe it is serial,* > *probably I am wrong (I don't have a way to know) but this operation is > very slow in High Replication.* > * > * > *My code uses heavily this construct and it is extremely fast.* > * > * > *Best,* > * > * > *--Constantine* > * > * > * > > * > > > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/google-appengine/-/DoYJ0jkPJ7cJ. > > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
