Burning CPU cycles on asynchronous API calls

[Wolfram Gürlich]

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

[Simon Knott]

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

[Wolfram Gürlich]

Hi Simon, CPU usage doesn't matter when your app is single-threaded because the entire instance will be allocated throughout the request.

But for multi-threaded apps the docs tell a different story:

"Multi-threaded instances can handle many concurrent requests. Therefore, there is a direct relationship between the CPU consumed and the number of requests/second."

....

"For example, if a B4 backend instance (approx 2.4GHz) consumes 10 Mcycles/request, you can process 240 requests/second/instance."

Unfortunately the docs won't tell how CPU consumption is actually measured. I guess API calls don't consume cycles - at least not while an RPC is underway. I'm not sure though if the clock stops ticking while a thread is laying asleep.

Wolfram

[Simon Knott]

Hi,

Ah, I see! Unfortunately I don't have an answer to your question - should be pretty easy to find out though. Cant you just set up two different requests, one which sleeps for bloody ages and one which spins at a high frequency and compare.? It is likely to be quicker than waiting here for an official answer...

Cheers,
Simob

[Stuart Langley]

Why are you not calling wait(), wait_any() or wait_all() depending on how you want to rendezvous the different async calls?

[Wolfram Gürlich]

Simon, I will try it out and report back on what I found out.

@Stuart - those wait..() calls seem to be specific to Phyton. I digged into the ApiProxy.java source code but it seems very different from phytons ApiProxy.

Wolfram

[Stuart Langley]

Ah ok - java futures. Bit harder to do WaitAny() style semantics but for you should still be able to call .get() rather than spinning manually.