Hi, This is because doing a strongly consistent fetch by key uses a transaction -- which means you'll always get the latest version. If you fetch a bunch of keys, these transactions are currently done serially which significantly slows the request. An eventually consistent fetch goes to the fastest datastore node and returns whatever version it has.
Robert On Thursday, July 7, 2011, Stephen Johnson <[email protected]> wrote: > Hi Pete, > Yes, I've also tested this and the speed improvement is VERY > noticeable. With the way that the documentation explains the > difference between the HR datastores STRONG and EVENTUAL settings you > would assume that getting by the key value would be the same speed > because according to the documentation gets always return the most > recent data. You would assume that queries on the other hand would be > the thing that would have the time difference because queries with the > EVENTUAL setting can use the replicas (unless an ancestor query) and > could have stale results. So something else is going on here that > hasn't been explained. It seems due to the speed increase with > EVENTUAL consistency on that gets by key are using the replicas (or > possibly master if that's the closest datastore) to return the entity > instead of the master, so what it could be is that with STRONG > consistency on you always use the master for all datastore operations > even when doing a get by key even though it could be handled by a > nearby replica and with EVENTUAL consistency you always use the > closest datastore which could be a replica or the master. Or it could > be something entirely else. Hopefully an informed Googler could > explain the subtle differences a little better. > Stephen > > On Tue, Jul 5, 2011 at 10:51 AM, Peter Murray <[email protected]> wrote: >> >> Greetings, >> In a small test retrieving 100 independent (non entity-group'd) entities by >> key (e.g. ds.get(keys) ) in an HR datastore, we found that the ReadPolicy >> significantly affected performance - with Consistency.STRONG set, the >> entities were returned in about 500ms (plus or minus), with >> Consistency.EVENTUAL set the entities were returned in about 50ms. Could >> someone please describe the practical differences between the two settings >> under an HR datastore? I had thought, from the I/O talk on the subject, >> that essentially in an HR environment you were not guaranteed strong >> consistency under any circumstances unless the entities are in the same >> entity-group. Of course, something is taking 10x longer - the question is, >> what am I getting for the 10x? >> Best, >> pete >> >> -- >> 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/-/apsAu6MR-BoJ. >> 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. > > -- ------ Robert Kluin Ezox Systems, LLC -- 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.
