Wow, thanks for the update, Mike! HR isn't 100% problem free yet. We're still working through some of the issues. Addressing infrastructure issues is one of our top priorities right now, but we can only do so much for master/slave, which has been through a bit of a rough patch lately.
I do want to urge people to look at migrating. We're getting really close to releasing a self-migration tool, but developers are still going to have to do some legwork. Make sure you understand the consistency guarantees of HR datastore! I'm hearing a LOT of misconceptions from people who don't understand get-by-key or ancestor questions. I recently did a talk about this. Check out these slides here (they're in English; don't worry about the title slide): http://www.slideshare.net/ikailan/2011-auggddmexicocityhighreplicationdatastore -- Ikai Lan Developer Programs Engineer, Google App Engine plus.ikailan.com | twitter.com/ikai On Tue, Aug 16, 2011 at 6:30 PM, Mike Lawrence <m...@systemsplanet.com>wrote: > Just burned several days with Google Enterprise Support trying to > troubleshoot intermittent long latencies; > unnecessary dynamic instance starts; and failures during dynamic instance > starts on a multi-threaded GAE Java app > running on Master/Slave (MS) data store. > > My typical app latencies on MS were under 1 second per request. > Periodically I'd see 5-20 second delays with very little traffic. > My app starts in under 3 seconds (stripes/slim3), so when instances failed > to start in 30 seconds, I suspected a GAE issue. > > After many attempts to resolve the issue, we finally decided to to try > switching to the High Replication (HR) data store. > All of the issues disappeared!!! The long latencies were all gone. My > traffic was easily being served with a single instance. > No more phantom dynamic instances. No more instance start crashes. > > I just volume tested my app. My median request went from 2.5 seconds on MS > to under 1 second on HR with 1000 simultaneous users. > > Previously I was paying for 3 always-on instances. With HR enabled, > there was no need for any always-on instances. > > So if High Replication is faster, and more stable, why should Google spend > valuable resources supporting Master/Slave? > Is the cost savings of MS worth all the issues it creates? Not for me. > > If you're experiencing similar problems on MS I highly recommend giving HR > a shot. > > FYI, migration to HR was trivial: > - created a new app id, > - deployed my app to the new id, > - used my app to initialize the data (this will be problematic for some), > - had google point the old app id to the new app id. > now serving from the original URL. > > > -- > 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/-/XCUAKZ5E1LYJ. > 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. > -- 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.
