Is Google Application Engine a good platform for a high-traffic chat website?

Question

I'm looking to create a high-traffic chat website, possibly with video streaming with some image manipulation happening on the server.

Scanning over the Channel API (http://code.google.com/appengine/docs/python/channel/overview.html) has made me hopeful this can be done without AJAX polling, and the general opinion is that GAE is very scalable.

I still have a few concerns:

1) Can it support tens of thousands simultaneous users that interact with each other in real-time without lagging? Is there a cap on CPU usage?

2) I'll (probably) be writing it on top of the J2EE framework. Does GAE guarantee that each new request will have access to a global in-memory datastore that will be available as long as the application is running on the server ("ServletContext" in Java-speak) and will be storing possibly gigabytes of data? Is there a memory cap?

3) Will the full J2SE and J2EE stack be available? Will I be able to include just any library I wish?

4) Are there better solutions for this kind of issue than GAE? I've been thinking about renting several dedicated servers, but this will go into the thousands/month...

Thanks in advance!

Carthy

Answer 1

To address your questions in order:

1. Yes, it can support tens of thousands of simultaneous users. I hope you're not expecting all of them to interact with each other simultaneously, though - fanning out 10,000 updates per user event isn't going to be terribly practical. CPU is a billed quota, so there's no cap as long as you pay for your usage.
2. The App Engine datastore is on-disk, not in-memory. Apps have access to the datastore (which is persistent) and memcache (which is in-memory, but a cache). Both are global across the whole app, not just the instance. Like CPU quota, there's no firm cap - you get what you pay for.
3. There's a whitelist of core JRE classes that excludes some functionality that would be unsafe to sandbox. Other than that, you can run whatever you want.
4. I think App Engine will suit your app quite well, with the exception of video streaming: There's not currently any App Engine based solution for that, so you'd have to use an external service for it. A major pro of App Engine is that the costs scale with usage, so you only pay for what you use.

Palmitin

Thanks Nick! No, it's not going to be n^2 message-fanning:) I was wondering about the memcache - how much more expensive is it than the datastore? And is it realistic to have real-time chat that's datastore-persisted in terms of responsiveness. Again - imagine tens of thousands simultaneous (or close to it) update and retrieve queries. How "close" is the datastore to the application? Does it get bogged down? What about CPU - can it get "exhausted"? Has it ever, for anyone using GAE? Sorry for the flood of questions, I just need every resource I can get. – Carthy

@Carthy Memcache is cheaper than the datastore - it's designed to be used as a fast cache for expensive data (including data fetched from the datastore), to speed your app up and make it cheaper. Datastore latency varies, but is generally on the order of 15-100ms depending on the operation you're doing - it should be your API of choice for persisting anything, including chat messages. CPU gets exhausted if you didn't budget enough for it - if that happens, increase your budget. Certain limits do have non-billed caps, but users who go over them can contact us to have them increased. – Palmitin

Answer 2

First, note that there is a free version and a paid version. I assume you are going to pay for additional quotas?

1. There is certainly a cap on CPU usage. I really doubt that your application is appropriate for GAE at all. Read this page about quotas. If you are doing video processing, you will probably find that you hit your daily CPU cap within a few minutes. You certainly won't support tens of thousands of users. (Maybe on the paid version you can last longer, but only about one order of magnitude more -- I still think it's infeasible).
2. Check the cap on the datastore size also. You get 1GB free, and have to pay for more. You don't have access to a global memory space (each request will potentially be handled by a different server), but you do have access to the global datastore.
3. There are limits on the libraries you can use. See the JRE class whitelist. If it isn't on that list, it isn't available. You can of course include any additional libraries if they are written in pure Java, but not if they use native code.
4. Yes, I think there are better solutions.

GAE is really intended for running small-to-medium level interactive websites, not doing high-performance things like video streaming. Sorry to be so pessimistic: you can make up your own mind from the info and links I provided.

Parvis

"GAE is really intended for running small-to-medium level interactive websites" - not true! We designed App Engine from the ground up to scale arbitrarily. – Palmitin

Thanks mguica! Can you please elaborate what you think would be the better options for a project? Perhaps static content and chat-pairing could be best done in GAE, but then send to other servers for chatting and video? I'd be happy for any suggestion, as this is very early in the development cycle and we're open to new directions – Carthy

Well, something with a lot of CPU and bandwidth! @Nick Johnson appears to be a Googler, so you might want to listen to him more than me. Despite the above statement, I think he mostly agrees with me (everything but the live video chatting is good, live video poses a problem here -- I think mostly because of the CPU and bandwidth involved, but there may be other technical hurdles). – Parvis

Yup. I just didn't agree with the blanket "not suitable" - video is the only thing here that doesn't really match. – Palmitin

Answer 3

Regarding the Channel API: note the message size limitation: "Messages are limited to 32K". Perhaps it could be possible to split the video stream into small chunks, but I don't think it's much practical or feasible. Also for the client to build back the original stream. Then no standard e.g. Flash player can be used.

Gaskill