* and if you have a production service running Master/Slave datastore, you should seriously consider migrating to HR datastore. If you have large amounts of data and this is unfeasible, please let us know via a billing ticket so we can figure out a plan for moving you.
Ikai Lan Developer Programs Engineer, Google App Engine Blog: http://googleappengine.blogspot.com Twitter: http://twitter.com/app_engine Reddit: http://www.reddit.com/r/appengine On Thu, Mar 3, 2011 at 11:19 AM, Ikai Lan (Google) <ika...@google.com>wrote: > Why are you being charged for idle instances? You are only charged for CPU > consumed by API calls. > > Don't make facetious comments about the SLA. Even if we never end up > supporting one (this is unlikely), we will be focusing on reliability from > the perspective of High Replication datastore, not Master/Slave. If you are > running a production service, you should not use Master/Slave datastore. > Ever. > > Ikai Lan > Developer Programs Engineer, Google App Engine > Blog: http://googleappengine.blogspot.com > Twitter: http://twitter.com/app_engine > Reddit: http://www.reddit.com/r/appengine > > > > On Wed, Mar 2, 2011 at 9:15 AM, Stephen Johnson <onepagewo...@gmail.com>wrote: > >> Awesome input! Thanks Simon. I've updated my list. Not looking good for >> HR. >> >> PROs >> >> ------------------------------------------------------------------------------------------------------------------------------------------------------------------- >> 1. No downtime during maintenance. >> 2. Latency/Spikes suppossedly decreased.?? >> 3. Faster gets/queries.?? >> 4. If Google ever does support an SLA it will only be HR (Ikai's post). >> But that might be 2020 or later :-) >> >> CONs >> >> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- >> 1. Cost: $.45/GB (seems expensive - is it worth it?) >> 2. Increased CPU (Testing is still early but it seems CPU cost is >> increased?? Is this just for puts with writing to multiple datacenters??) >> 3. Instances last longer in idle state causing a CPU charge for next >> request while idle. (This has never been addressed or acknowledged by Google >> but many have complained about it.) This may be what is causing #2 above. >> (See excellent comments by Simon Knott). >> 4. Increased latency time for Memcache requests perhaps 2 to 10 times >> longer?? >> 5. Increased loading time for loading requests. Almost double?? >> >> >> >> On Wed, Mar 2, 2011 at 10:04 AM, Simon Knott <knott.si...@gmail.com>wrote: >> >>> HR instances definitely seem to last longer than M/S ones - I've had >>> instances last for days on my HR app, which is only in development. >>> However, that's highlighted a strange problem in that you seem to be >>> "charged" for idle instances. >>> >>> The very rough idle "costs" are: >>> >>> 1hr idle = additional 2000 CPU_ms for next request >>> 2hr idle = additional 4000 CPU_ms for next request >>> 4hr idle = additional 8000 CPU_ms for next request >>> ... linear increase to: >>> 24hr+ idle = additional 45000 CPU_ms for next request >>> >>> This probably isn't a major problem for apps which are busy, but it >>> should be taken into account for small apps I guess! >>> >>> Another thing I've noticed is that HR apps have additional latency for >>> MemCache API calls in the region of 2-10 times longer. I've tested my app >>> in both M/S and HR and the HR version consistently has MemCache API Gets >>> taking 20ms on average, for tiny amounts of data, which only take 4ms on the >>> M/S version. >>> >>> Loading requests seem quite long on HR instances as well, almost double >>> that of the M/S. >>> >>> *NB. *It should be noted that all of my experience is based on a single >>> app which is still in development, so all of my observations may not ring >>> true for real-life, high-throughput apps. >>> >>> -- >>> 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. >>> >> >> -- >> 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. >> > > -- 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.
