Channel API CPU usage

[Andy Kim]

The new Channel API is awesome and it opens up many possibilities on what I can do with GAE. I have noticed however, that creating a channel takes about 2800 ms of API CPU time. Is everyone else seeing similar times or am I doing something wrong here?

[Bart Thate]

Hoi Andy,

these times are normal and can take upto 10 seconds i read. Normal for me is 3 seconds.

@jsonbot Heerhugowaard, Netherlands

programming schizofrenic - http://jsonbot.appspot.com

On Sat, Dec 11, 2010 at 1:37 AM, Andy Kim <andy...@gmail.com> wrote:

The new Channel API is awesome and it opens up many possibilities on what I can do with GAE. I have noticed however, that creating a channel takes about 2800 ms of API CPU time. Is everyone else seeing similar times or am I doing something wrong here?

--
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.
To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.

[Tom Wu]

Hi Andy,

Here is 2770ms. Compare to using the beaconn + urllib, the channel api really cost a lot.

   
Tom Wu

2010/12/11 Andy Kim <andy...@gmail.com>

The new Channel API is awesome and it opens up many possibilities on what I can do with GAE. I have noticed however, that creating a channel takes about 2800 ms of API CPU time. Is everyone else seeing similar times or am I doing something wrong here?

--

[Andy Kim]

Assuming that a channel setup costs 2.77 seconds, having just 10,000 active users setup 4 channels per day would cost $92.30 per month. That's not counting any CPU costs for actually sending messages.

At that rate, I can't really use the channel API as much as I'd like and I have to look at alternatives such as Beacon now that I know how cool this technology is.

Here's to hoping that the GAE team can bring down the cost of setting up a channel by at least a factor of 10.

- Andy Kim

On Dec 10, 2010, at 7:53 PM, Tom Wu wrote:

Hi Andy,

Here is 2770ms. Compare to using the beaconn + urllib, the channel api really cost a lot.

<1E3.gif>    <1E3.gif>

[Moishe]

> Assuming that a channel setup costs 2.77 seconds, having just 10,000 active users setup 4 channels per day would cost $92.30 per month. That's not counting any CPU costs for actually sending messages.
>
> At that rate, I can't really use the channel API as much as I'd like and I have to look at alternatives such as Beacon now that I know how cool this technology is.

Better docs on Channel API quota use are coming, but the reason the
CPU charge is so high is that the CreateChannel charges up-front for 2
hours of connect time by clients. It is true that if you have the same
user connecting repeatedly for a short time but spread out over
periods of time longer than two hours (obviously degenerate case would
be connecting for a couple of minutes every two hours and one second),
the charge will be high. One thing I'm looking at is the ability to
create a token that expires after an application-specified period, if
your application's usage patterns warrant it.

Note that you can store the token for re-use in eg. a cookie so you
don't need to regenerate it more frequently than every two hours.

Sending a message doesn't charge any CPU time at all (since the
connection's already established), just outbound bandwidth.

[Andy Kim]

> Better docs on Channel API quota use are coming, but the reason the
> CPU charge is so high is that the CreateChannel charges up-front for 2
> hours of connect time by clients. It is true that if you have the same
> user connecting repeatedly for a short time but spread out over
> periods of time longer than two hours (obviously degenerate case would
> be connecting for a couple of minutes every two hours and one second),
> the charge will be high. One thing I'm looking at is the ability to
> create a token that expires after an application-specified period, if
> your application's usage patterns warrant it.
>
> Note that you can store the token for re-use in eg. a cookie so you
> don't need to regenerate it more frequently than every two hours.
>
> Sending a message doesn't charge any CPU time at all (since the
> connection's already established), just outbound bandwidth.

It being the first version, I was hoping that it took so much CPU time because it had room for improvements. Does this mean that it's unlikely for the CPU costs of setting up a channel to come down?

[Remigius]

Andy,

this amounts to 0.01$ (1 cent) per user per month. too high?

Moishe,

Why don't you rather think along the lines of introducing a (maybe
application specified) timeout, i.e. the token expires after there's
no successfully delivered message for a certain amount of time? This
would avoid a lot of house-keeping needed to regenerate expired tokens
for still connected users in most usage scenarios (that I can
imagine). Of course, improvements on the CPU usage are welcome as
well...

Cheers, R.

[Flori]

2770ms too, also it appears a yellow alert in the "current
load" (dashboard) table for each request.. and i agree it can take
upto 10 seconds. A load time/CPU usage which really is not acceptable,
ins't it? (but it seems to be no problem on localhost). Are there any
plans to improve performance?

I started a similar thread due this issue but there were no answers
yet:
http://groups.google.com/group/google-appengine-java/browse_thread/thread/3285f61655ace488

On 11 Dez., 04:53, Tom Wu <service.g2...@gmail.com> wrote:
> Hi Andy,
>
> Here is 2770ms. Compare to using the beaconn + urllib, the channel api
> really cost a lot.
>

> [?]    [?]
> Tom Wu
>
> 2010/12/11 Andy Kim <andyki...@gmail.com>

>
>
>
>
>
>
>
> > The new Channel API is awesome and it opens up many possibilities on what I
> > can do with GAE. I have noticed however, that creating a channel takes about
> > 2800 ms of API CPU time. Is everyone else seeing similar times or am I doing
> > something wrong here?
>
> > --
> > 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.
> > To unsubscribe from this group, send email to

> > google-appengi...@googlegroups.com<google-appengine%2Bunsubscrib e...@googlegroups.com>
> > .

> > For more options, visit this group at
> >http://groups.google.com/group/google-appengine?hl=en.
>
>
>

>  1E3.gif
> 3KAnzeigenHerunterladen

[download]

Right now my only application using the Channel API only use it for a
few minutes at a time.
Also, I recall from the Google presentation on Channel API one of the
selling points was that it wouldn't use our application quota for the
constant polling.
Charging for two hours up-front rather defeats that.
We may as well use a custom long-polling solution or one of the 3rd-
party push APIs (pusher, beacon, etc) since it would be cheaper, and
the 3rd-party APIs have more features (like shared channels).

My point is, if you want to see any sort of wide-spread adoption of
this API, you're going to need to solve this somehow.

[Nick Johnson (Google)]

Hi,

2770 milliseconds is 2.7 CPU seconds, which works out to a cost of $0.000076 dollars per call, or seven one-thousandths of a cent. This doesn't seem like it will be outrageously expensive, and I suspect you'll find it challenging to find a third-party service that works for a lower total cost.

Nevertheless, wanting shorter-lived channels is a valid use case - so please do file a feature request for it.

-Nick Johnson

--
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.
To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.

--
Nick Johnson, Developer Programs Engineer, App Engine
Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration Number: 368047

[Peter Petrov]

Hi Nick, Moishe,

Specifying the expected channel lifetime at setup time is not very useful - because we _do not_ know in advance how long the user will stay. Some users will stay on the page longer, others will look quickly and go somewhere else. Reusing the channel tokens is not an option for some of us.

That's why I think CPU usage should be charged at _disconnect_ time instead - based on how long the channel was actually connected. This shouldn't be too hard to implement (having in mind that you are already working on disconnect notifications, as Moishe said).

Best regards,

Peter