*This is the best thread during this month!

On Racetown we've similar issues. Based on our experience having different 
services such as GAE and Rackspace in the same project (ie scores vs. the 
rest of the game) tend to complex things. 
After a while you will need to share data between both technologies 
incurring in data migration needs. For instance sharing user between 
Rackspace hosted score system and the rest of the game.

We did that on GAE hosted game with metrics logging on Rackspace. 
Maintenance of that solution was painful because Rackspace Linux/Apache 
maintenance, monitoring and also integration between GAE and this service.  
Finally we opted for paying a little more and having everything on GAE side.

On the other hand, I think you could simplify a little your scoring 
solution. What if you hold user’s scores on sharded MemCache entries and 
after a while you get all of them and save the result on the DataStore?*

On Thursday, August 9, 2012 11:04:32 AM UTC-3, Jeff Schnitzer wrote:
>
> I generally am sympathetic to "GAE costs more because it offers more". 
>  But there's a finite limit to what that "more" is worth.  2X?  3X? 
>
> Consider that those 10 B1s are barely keeping up with a load of 2k 
> users.  A single $11/mo Node instance handles more than 10k users in 
> my tests.  As we've been talking about this, Richard's user #s are 
> growing, and now he needs more than 10 B1s.  So to put this in proper 
> comparison, even _with_ the discount that isn't currently available, 
> we're comparing cost to support 10k users: 
>
> 50 B1s = $1,800/mo 
> 2 Node instances (the second for redundancy) = $22/mo 
>
> We're talking almost 100X.  Two full orders of magnitude more expensive. 
>
> But yes, I would happily offer the score-server service for $360/mo, 
> let alone $1800!  However, Richard is smart enough to run these on his 
> own.  My VPS instances have uptimes of 129 days, and that's just 
> because I did a kernel upgrade. 
>
> BTW, my goal in having this conversation is to encourage you guys to 
> make backends either:  1) a lot cheaper or 2) perform a *lot* better. 
> Ideally both. 
>
> Jeff 
>
> On Thu, Aug 9, 2012 at 12:18 AM, Takashi Matsuo 
> <tma...@google.com<javascript:>> 
> wrote: 
> > First of all, thank you for the detailed cost comparison and the 
> > honest feedback. We really appreciate it. 
> > 
> > The data itself is not very far from what I observed in my test. 
> > Certainly, we should try making the backends cheaper. The easiest fix 
> > will be this issue: 
> > http://code.google.com/p/googleappengine/issues/detail?id=7411 
> > 
> > It will reduce the cost by 5/8(if the discount rate is the same as the 
> > one for frontend), so it'll be $360/month for 10 B1s. 
> > 
> > Besides the cost, we should also improve the performance itself. 
> > 
> > You might say 'It's still insane', however, I don't think so, because 
> > App Engine backends provides other goodies like high availability, 
> > redundancy, maintenance-free nature from the start. 
> > 
> > Please think this way. Would you like to offer a score-server service 
> > for Richard by yourself at a cost of $360/month? Besides running a 
> > single node.js server, you also need to run a spare server, need to 
> > create a monitoring/fail-over mechanism, need to have a support 
> > channel when in trouble, and sometimes need to diagnose any network 
> > problem between App Engine and your server. 
> > 
> > If the answer is yes, probably it's a good business chance for you ;) 
> > 
> > I'm not saying that App Engine is perfect, but i just wanted to point 
> > out that your comparison lacks(maybe it's intentional) a consideration 
> > for the important aspects of App Engine. 
> > 
> > However, your feedback is still invaluable to us. Thank you as always. 
> > 
> > Regards, 
> > 
> > -- Takashi 
> > 
> > 
> > On Thu, Aug 9, 2012 at 3:31 PM, Jeff Schnitzer 
> > <je...@infohazard.org<javascript:>> 
> wrote: 
> >> On Wed, Aug 8, 2012 at 11:01 PM, Kristopher Giesing 
> >> <kris.g...@gmail.com <javascript:>> wrote: 
> >>> Do we know for sure that front ends are any faster?  Their individual 
> >>> throughput limits might just be masked by having more of them spin up. 
> >> 
> >> I expect frontends are about the same.  But frontends can't aggregate 
> >> scores so they aren't really an issue in this test.  If you want to 
> >> feel even worse for Richard, he's paying for what seems like an 
> >> unreasonable number of F1 instances too... but for some reason that 
> >> seems less frustrating than the totally unnecessary need to add a 
> >> second equivalent number of backends. 
> >> 
> >> Jeff 
> >> 
> >> -- 
> >> 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-a...@googlegroups.com<javascript:>. 
>
> >> To unsubscribe from this group, send email to 
> google-appengi...@googlegroups.com <javascript:>. 
> >> For more options, visit this group at 
> http://groups.google.com/group/google-appengine?hl=en. 
> >> 
> > 
> > 
> > 
> > -- 
> > Takashi Matsuo | Developer Advocate | tma...@google.com <javascript:> 
> > 
> > -- 
> > 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-a...@googlegroups.com<javascript:>. 
>
> > To unsubscribe from this group, send email to 
> google-appengi...@googlegroups.com <javascript:>. 
> > 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 view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/mMm23l239eMJ.
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.

Reply via email to