AppEngine actully has XMPP intergtation http://code.google.com/appengine/docs/python/xmpp/
And the Channel API http://code.google.com/appengine/docs/python/channel/ which should eliminate the need for polling AJAX requests yourself. Could probably use the matcher API (renamed Speculative Search API) http://groups.google.com/group/google-appengine/browse_thread/thread/5462e14c31f44bef to perform dispatching of messages, again eliminating the need for the polling on the datastore. On 23 February 2011 08:29, Joonas Pihlajamaa <[email protected]> wrote: > Hi all, > > I'm trying to build chat functionality into my Google App Engine web > application. The basic idea is that User loads a chat page that employs AJAX > calls to poll new chat messages in the channels he/she is following every > few seconds, and user can also write to the channels using AJAX. > > A simple channel entity with a list property containing message strings is > OK for channels with a few users and infrequent updates, but once a channel > becomes "hot" (likely to happen for the purpose I have in mind), there's > suddenly 300 users polling a single channel entity every few seconds, and > new lines being added every few seconds. Once the entity contains something > like 1000 message strings, this starts to sound a bad idea. > Creating a new entity type for message line with timestamp is also possible, > but polls would then be of type "give me all messages since timestamp X", > and every poll would need a filtered query into message pool, and with a > thousand users this would mean something in the ballpark of 200 queries per > second. Also, this solution doesn't play well with memcache. Changing > timestamp to incremental counter would improve the situation, but I still > don't know if it's efficient to cache each chat message as a single object > in memcache? > The solution I'm now considering would be to "page" a chat channel, so one > chat page entity would contain something like 50 messages at most (as a list > type property), and when that limit is reached, a new page is created. Each > channel object would have a reference to the current page and previous page, > so new users joining the channel would have quick access to >50 of the > latest messages. Pages would also lend themselves well for memcaching. A > poll would then be of type "If have the messages until page 3, message 23 - > what's new?". > > Any ideas or comments on the different options? Am I worrying too much about > this? I know this currently is not issue, but my aim is that the data > structure should gracefully and efficiently handle something like 2500 > simultaneous users, each polling typically one to ten different channels and > contributing to one or two. > > -- > 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. > -- 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.
