Hi, Why do you care about CPU cycles? The pricing model no longer cares about CPU usage, it only cares about instance allocation time. As far as I'm aware the scheduler cares the most about the entire length of the user request, rather than what happens within that request.
Cheers, Simon On Monday, 5 March 2012 14:13:52 UTC, Wolfram Gürlich wrote: > > Hi, in my app I have two concurrent asynchronous API calls. I want to act > on whichever call completes first (either memcache or datastore). > > What's the best way to wait on a result without burning CPU cycles? > Currently I'm checking periodically and call Thread.yield() on every round. > Since I'm not blocking on a synchronous API call, does the wall-clock-time > waiting there still count against my "Runtime MCycles"? > > Will it make a difference in terms of "Runtime MCycles" if I try to save > real CPU cycles or could I just as well be using a simple loop to wait on > one of the calls to complete? > > I assume that in contrast time spent waiting on synchronous API calls does > not count towards my "Runtime MCycles". Am I correct here? > > Besides latency - will "Runtime MCycles" affect the way the scheduler > treats my app at all? (the number of concurrent request per instance maybe?) > > Wolfram > -- 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/-/GDD76HoKo7MJ. 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.
