On Fri, Aug 3, 2012 at 10:04 PM, Richard <[email protected]> wrote:

> Connection pooling might be a good idea.  Since there are people in every
> game round and each round is 3 minutes, the SQL db will always be up.  I
> did try it, but I think my connection from home was limited.
>
> RE: SQL solution:   Can some of you with LOTS of bandwidth (from a *nix
> machine), please AB the following URL:
>
>      http://sven-anagramhero.appspot.com/client/loadtest
>
> Try at least 1000 connections with 250-500 concurrent and report back here
> please.
>
> WRT costs:  DB read/writes are around $3/day.  Whereas 10 B1 backends
> would be almost $20/day.
>
> In addition, the B1 solution does not scale.  Lets say the app suddenly
> gets a lot of new users.  Now I need to update the backend.  Additionally,
> peak load is approximately 4x the lowest value.  Now, for part of each day,
> I need to have enough instances to handle the peak load just doing minimal
> work.  This is not scaling automatically.  I always need to pay the maximum
> of whatever is needed to handle peak load.... or else update the backends
> every few hours to add/remove B1's.  Not exactly fulfilling the automatic
> scaling promise!


Good point, but I think you can workaround with dynamic backend instances,
although you need to care about shutdown scenario. Here is just a
theoretical implementation.

* Define one resident backend instance for handling the scores from backend
instances which are shutting down. Let's call this instance as a 'master'.
* Define dynamic backend with appropriate max instances according your
needs, setup a shutdown hook which will pass the scores to the master
instance.
* When reaping, you can ask dynamic instances as well as the master
instance.

That way, you can have the autoscale capability with minimum cost.

Maybe I can create a prototype implementation hopefully early next week. Of
course, you can create your own.

-- Takashi



>
>
>
>
> On Friday, August 3, 2012 3:49:24 AM UTC-4, Mauricio Aristizabal wrote:
>>
>> Takashi, is there some more detailed information on why Google doesn't
>> encourage using a connection pool?  Is it simply to encourage allowing the
>> db instance to wind down instead of being kept alive only by pool
>> connection health checks?  If so I'm sure it could be configured to avoid
>> this.
>>
>> It does seem to me that it could reduce Richard's costs drastically, by
>> 2/3 just on the writes to the db by his own numbers.
>>
>> I've been using pooling without issue for several months now, though
>> admittedly with very little traffic so far, so if you think this is going
>> to get me in trouble later I'm very eager to hear why.
>>
>>
>>
>> On Fri, Aug 3, 2012 at 12:28 AM, Richard Watson <[email protected]
>> > wrote:
>>
>>> What are the performance characteristics of connecting to Google Compute
>>> Engine?  Maybe slap the in-memory app onto that.
>>>
>>>  --
>>> 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/-/**pTFagZqQkx4J<https://groups.google.com/d/msg/google-appengine/-/pTFagZqQkx4J>
>>> .
>>>
>>> To post to this group, send email to 
>>> google-appengine@googlegroups.**com<[email protected]>
>>> .
>>> To unsubscribe from this group, send email to
>>> google-appengine+unsubscribe@**googlegroups.com<google-appengine%[email protected]>
>>> .
>>> For more options, visit this group at http://groups.google.com/**
>>> group/google-appengine?hl=en<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/-/-NIqVbhGPw4J.
>
> 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.
>



-- 
Takashi Matsuo

-- 
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.

Reply via email to