>From my experience in the wave sandbox, and I'm sure many others can confirm this, the current wave implementation has some very serious scalability problems. As long as a wave is small and the number of participants is low, everything works like a charm. But once the wave gets bigger or the number of participants grows too much, it gets very sluggish, sometimes even barely usable.
There are some impressive optimizations in the OT algorithm, but when it comes to moving data around, the current implementation seems rather naive. Here are a few ideas to speed things up: 1. Allow a wave to be loaded in "pages". I put this in quotes because there's no concept of actual pages in wave. When I say "page" I mean a single screen-height long piece of a wave. The actual length of a "page" would be determined by the client. 2. Make a distinction between pages that need real-time updates and those that don't. Only send real-time updates to the client for the pages that the client has asked for real-time updates to. For compatibility, if the client has not specified any pages, assume that it wants to get real-time updates for the whole wave. This needs support on the protocol level - both server / server (federation) and client / server. But the groundwork for this can be laid out in the federation protocol even before there is a C/S protocol. 3. On the client, start by loading only the currently visible page. After the current page has loaded (and only after!), load the page below that and the page above that to speed up client-side scrolling. Do this in the background if possible. Once those are loaded, load the next closest pages and so on. This should dramatically speed up apparent loading times for large waves, since interaction can begin as soon as the current page is loaded. 4. Cache every page that is loaded, so that it doesn't need to be loaded again. 5. Only load as many pages as the client can handle without slowing down due to memory constrains or other client-side limitations. A local file store can help with the memory issues if it's supported. 6. Still on the client, only request real-time updates for a page when it gets into view (or just below / above the view). Make sure to tell the server you no longer need real-time updates for pages outside the view. The client may update out-of-view pages at a lower frequency to make sure they don't get too far out of sync. 7. If a wave is not being viewed by anyone else, send deltas to the server less frequently to reduce message overhead and strain on the server. Concatenate operations on the client before sending them. These are just some ideas to get the discussion started. What else can be done? Is there anyone here who has experience writing real-time multi-player games, especially MMO? I think there may be a lot of optimizations that can be taken from that area by analogy. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Wave Protocol" 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/wave-protocol?hl=en -~----------~----~----~----~------~----~------~--~---
