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.
