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 On Fri, Dec 17, 2010 at 7:08 AM, download <[email protected]> wrote: > 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. > > On Dec 11, 7:37 pm, Moishe <[email protected]> wrote: > > > 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. > > -- > 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]<google-appengine%[email protected]> > . > 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 -- 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.
