2

Google app engine seems to have recently made a huge decrease in free quotas for channel creation from 8640 to 100 per day. I would appreciate some suggestions for optimizing channel creation, for a hobby project where I am unwilling to use the paid plans.

  1. It is specifically mentioned in the docs that there can be only one client per channel ID. It would help if there were a way around this, even if it were only for multiple clients on one computer (such as multiple tabs)

  2. It occurred to me I might be able to simulate channel functionality by repeatedly sending XHR requests to the server to check for new messages, therefore bypassing limits. However, I fear this method might be too slow. Are there any existing libraries that work on this principle?

mkwn
  • 23
  • 2
  • 8640 channels will cost you $0.86. Is that really a substantial enough cost to refactor your entire app around? – Nick Johnson Dec 06 '11 at 23:30
  • it's a hobby app that I'm making mainly for fun and experience, so I don't mind having to rewrite parts of it. Converting to a paid app will apparently cost a minimum of 2.10 per week which is over 100 per year. While very affordable, it isn't an investment I'm willing to make for something of such little consequence. – mkwn Dec 08 '11 at 03:08
  • https://github.com/diy/intercom.js/ is currently the best solution I think – inf3rno Oct 03 '13 at 23:32

1 Answers1

5

One Client per Channel

There's not an easy way around the one client per channel ID limitation, unfortunately. We actually allow two, but this is to handle the case where a user refreshes his page, not for actual fan-out.

That said, you could certainly implement your own workaround for this. One trick I've seen is to use cookies to communicate between browser tabs. Then you can elect one tab the "owner" of the channel and fan out data via cookies. See this question for info on how to implement the inter-tab communication: Javascript communication between browser tabs/windows

Polling vs. Channel

You could poll instead of using the Channel API if you're willing to accept some performance trade-offs. Channel API deliver speed is on the order of 100-200ms; if you could accept 500ms average then you could poll every second. Depending on the type of data you're sending, and how much you can fit in memcache, this might be a workable solution. My guess is your biggest problem is going to be instance-hours.

For example, if you have, say, 100 clients you'll be looking at 100qps. You should experiment and see if you can serve 100 requests in a second for the data you need to serve without spinning up a second instance. If not, keep increasing your latency (ie., decreasing your polling frequency) until you get to 1 instance able to serve your requests.

Hope that helps.

Community
  • 1
  • 1
Moishe Lettvin
  • 8,462
  • 1
  • 26
  • 40