That is as I suspected. And yeah... that's a lot of cpu hours! A slick solution would be a Google Chat integration where you could limit it to your domain like they do with Google Apps for your Domain, but without the cost per user.... Or, I'd even be happy with being able to create my own jaiku stream within the app where my users could post to it. I believe I remember reading something about that now that Jaiku is running in GAE.
Thanks a bunch for the input, Jose. On Apr 2, 5:06 am, José Oliver Segura <[email protected]> wrote: > On Thu, Apr 2, 2009 at 6:13 AM, ryandscott <[email protected]> wrote: > > > I'm wondering what the best way to implement a chat system would be. > > Currently, I have a javascript timer that goes off every x seconds to > > query the database and return the list of chats. I keep my list to a > > certain number of chats, but it seems that the way I'm doing the whole > > process is a fairly poor design. > > Given the natural limitations of the HTTP protocol, I don't think you > can do it much more better than this. HTTP is based on > request/response paradigm and thus, the only way to simulate > server-initiated updates is to do polling using any of the available > options (timed requests/ajax/comet/fancynamehere, etc.) > > You must also add to the limitations of the HTTP protocol the > restrictions of the GAE environment (maximum number of simultaneous > requests, maximum amount of time allowed to serve a request, etc.), > and this will narrow your available options to -probably- just one: > periodic polling to some URLs from the client in order to > emulate/simulate server updates. > > Take care about this, since this option, depending on your application > and update intervals, may exhaust your free quotas or your bugdget > very quickly. For example, supose you have 40 chat rooms per day with > 40 users each one, with a lifespan of 2 hours per chat, with clients > polling for updates each 5 seconds (that is, 12 status update requests > per minute, just to make the whole thing look like "real time"), this > sill result in: > > 40chats x 40uses x 120min x 12 reqs/min = 2304000 requests > > Assuming 200ms-cpu per request (process request, lookup > memcache/datastore, write request, etc.), this yields: > > 2304000 requests * 200ms-cpu/requests = 460800000 ms-cpu = 128hours cpu > > (If you think 40 chats / 40 users is too much, just make those numbers > smaller and increase the reqs/second from 12 to 24/60, since an update > each 5 seconds could probably result in jumpy updates. Also, the > 200ms/request figure is estimated, but I doubt you can lower it more, > since you *must* do something with memcache/datastore in the server, > in order to compute and send updates) > > Right now it's very hard to interpret how to compute exact costs since > there are many different figures to look at: cpu time, datastore cpu > time, billable/not billable, current free limits / future free limits, > etc., but "128 cpu hours" falls beyond any of the figures in that > page, so this means that either your app will stop working after some > activity (if you don't have billing enabled) or that you are going to > pay *a lot* due to polling and the fact that it incurs in CPU usage > (128 cpu-hours/day, woud represent 12.8$/day and aprox 384$/month, > which means you'll probably must start writing a business plan :-) ) > > Besides that, there's some movement right now around HTML 5 and the > idea of "WebSockets", which specifications are on track to be > standardized (I don't know exactly at which point they are), but I > would'nt bet for it to be included in short time in GAE (maybe some > response from any of the Google team members here could be great). > > Also, there's something related to XMPP/GAE integration on the > roadmap, in order to make GAE applications able to send/receive XMPP > messages, but I believe that (a) this would imply that your chat's > users must be registered/authenticated agains an XMPP server and that > (b) you would need a third element -an XMPP server- to appear into > action... well, none ot these scenarios look very promising right now > (without the cited business plan, of course :-) ) > > Hope that helps. Best, > Jose --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
