Difference between revisions of "Project Motivation"

From Second Life Wiki
Jump to navigation Jump to search
Line 13: Line 13:
Scalability of concurrent users:
Scalability of concurrent users:
:* 50 - 100 million concurrency (on whatever device)
:* 50 - 100 million concurrency (on whatever device)
Scalability for events (concurrent users in a single region):
:* 20 thousand per region ([[Talk:Project_Motivation|simple maths, please discuss on Talk page first if you have an issue with this]])


These are the primary numbers that drive the need for the architecture.  In Zero's view, these numbers will almost certainly happen, no matter what form virtual worlds take.  These numbers will not be possible with the grid right now and additionally some more use cases need to be solved like connecting 3rd party hosted regions to the grid.
These are the primary numbers that drive the need for the architecture.  In Zero's view, these numbers will almost certainly happen, no matter what form virtual worlds take.  These numbers will not be possible with the grid right now and additionally some more use cases need to be solved like connecting 3rd party hosted regions to the grid.

Revision as of 00:57, 17 October 2007

According to Zero Linden, the project was motivated by thoughts a year ago when Second Life was growing rapidly and Linden Lab was thinking about how to scale the grid.

There have been two timeframes set back then: The next few months and the next years. This architecture discussion is about the next years.

Scary numbers

If we assume that virtual worlds will be a significant part of the future, then the following numbers might not be so far off:

Scalability of world extent:

  • 60 million regions (probably more) (60 was mentioned here by Zero Linden )

Scalability of world population:

  • 2 billion users

Scalability of concurrent users:

  • 50 - 100 million concurrency (on whatever device)

Scalability for events (concurrent users in a single region):


These are the primary numbers that drive the need for the architecture. In Zero's view, these numbers will almost certainly happen, no matter what form virtual worlds take. These numbers will not be possible with the grid right now and additionally some more use cases need to be solved like connecting 3rd party hosted regions to the grid.

Additional scaling factors

The above scary numbers stem from population pressure alone, but there are other areas of growth which compound the impact of those numbers still further. We might, or might not, take such numbers as guidelines that the architecture we devise should support. While we would like the architecture to support as many possible feature sets, and implementation strategies as possible, various numbers may or may not be achievable.


  • Concurrent users engaged in a single event will want to rise.
  • Prim count expectations grow naturally. Limiting them to current values is not tenable.
  • Scripting load will grow roughly in proportion to prim numbers, as well as proportional to population through attachments.
  • Current growth is tiny compared to what will happen when TV-led events like CSI:NY/SL turn SL mainstream. Concurrent usage pressure will explode.

There also are numbers that are not expected to grow but still may have a significant impact on technical decisions regarding architecture, so they may be used to "anchor" anticipations and as a base for designing the rest of the architecture. These are the expected end-user capacities:

  • The maximum number of concurrent interactions with other people per player is not expected to increase. There is only so many people we can consider and be attentive to simultaneously, that making more people visible or heard makes no useful difference or even degrades experience.
  • The maximum chatting output per player isn't growing anytime soon either.
  • The maximum number of concurrent world interactions is pretty fixed: there is only so many prims we can modify, scripts we can interact with, objects we can manipulate simultaneously ; and we can only manage to maneuver so fast, that flying, driving and taking sharp turns faster is impractical.
  • The update frequency required to simulate smooth movement or make a curved, arbitrary trajectory not appear disjointed or jerky is not going to increase over a few dozen Hz, and there is only so many moving objects we can be attentive to and in whose movement we can detect discrepancies.