Scalability VAG

This is an early draft so scope and focus are still fairly open. Please add comments to the Talk:Scalability VAG if you have slightly different concerns so that we can try to converge on a common viewpoint. Where appropriate, this discussion could expose the need for related sub-VAGs in this area.

Purpose

The Scalability Viewpoint Advocacy Group exists to provide input for architectural design that is focused on the expressed Project Motivation of the project and the banner motto of AWG: "Making the Grid a Scalable Place".

More specifically, the Scalability VAG is concerned with identifying all important dimensions of scalability, determining the relevant scaling pressures as numerically as possible, establishing both the end limits and realistic near-term goals for scalability and scaling, and ensuring that these concerns are addressed in the evolving architectural design.

The Scalability VAG is a technical VAG.

The Scalability VAG is an umbrella VAG

In view of the magnitude of the task described above, it is expected that the Scalability VAG will devolve into separate VAGs each concerned with one dimension of scalability, as well as other specialized VAGs. To this end:

1. This Scalability VAG will seek to avoid specialization, to avoid overlap with sub-VAGs.
2. This Scalability VAG will provide references, analysis and tools as a resource for sub-VAGs.
3. Where other VAGs have viewpoints that imply the need for scalability but lack technical expertise or interest:
   • This Scalability VAG will adopt the relevant scalability concerns, possibly in a sub-VAG.
   • This Scalability VAG will assist towards conformance of the architecture with those concerns of that VAG.

See the Architecture Working Group and the Viewpoint Advocacy Groups for more information.

Known sub-VAGs:

• Event Scalability VAG

Areas addressed by this viewpoint

• Identification of all dimensions of scalability relevant to this platform.
• Scalability of the new system architecture in all dimensions of population growth:

• For each dimension identified:

• determination of the relevant growth metrics
• assessment of current constraints on scalability
• consideration of new designs with improved scalability
• detailed scalability analysis of all design proposals
• measurement and presentation of levels of conformance

• Specific elements of maintenance scalability, especially in regard to graceful degradation:

• Dynamic scalability of system architecture in response to:

• anomalous growth of total population over short periods of time
• variation of concurrent online users over the daily and weekly cycle
• anomalous population dynamics resulting from media events and special holiday periods
• unplanned resource malfunction and equipment failure
• withdrawal of services or resources for maintenance.

• Tools and methods by which scalability of designs and systems can be evaluated and documented.

Areas not addressed by this viewpoint

• Scalability of interoperation is not addressed at this time, namely the rate and ease or otherwise with which worlds and grids can interconnect with the SL grid and vice versa.
• Functional scalability is not addressed at this time, for instance the rate and ease or otherwise with which worlds and grids can add new service definitions while maintaining interoperability.

Current State of Play

• It's hard to know exactly what to analyze for scalability in the new architecture until we know how the grid resources are partitioned into REST services. Candidate partitionings have not been proposed yet, so this is on hold while work continues in the REST Services VAG and through discussion with Zero at his Office Hours.
• Some tools were deemed appropriate for applying actual workloads to the reference implementation of REST services so that we could spot descaling trends early on. That work is in progress in the Multi-Process Client VAG -- draft, and despite that still being in draft form and at a very early design stage, there is reasonable progress there. (Feel free to join. :P)
• The analysis of mitigating factors which reduce the arithmetic scalability requirements of regions to below the numbers calculated in Project_Motivation was started but not completed. Completion of this work is a priority.

Scalability VAG Glossary

The following terms and abbreviations are defined for this viewpoint with the purpose of reducing repetition and providing joint terms of reference for stakeholders of this VAG. A small handful of terms overlap with those in the main AWG glossary, but this is only to localise this VAG's lookups and to avoid cluttering up the main glossary with detailed scalability examples and explanations.

Multi-Factor Scalability Limit (MFSL)

A scalability limit which results from the combination of two or more partially disjoint or simpler scalability limits, ie. PPSLs. It is of high practical value in specifying project scalability goals in a concise manner and without engaging further in-situ scalability analysis or discussion.

Example: under a (hypothetical) premise that dislike of crowds reduces event attendance by half when events attract more than 1,000 participants, then a PPSL scalability end-limit of 20,000 would be reduced to an MFSL of 10,000 participants.

Population-Proportional Scalability Limit (PPSL)

A scalability limit which results from direct arithmetic scaling of a current value along a given dimension in proportion to growth in a related dimension. This is a raw scalability limit, in the sense that it is as far as possible unaffected by any other up-scaling nor down-scaling factors. As such, it provides a well-defined element for use in scalability analysis rather than an actual target for scalability.

Example: the end limit of scalability in the number of avatars at an event, calculated from the projected growth in user population (2 bn) versus the current level of interest in attending a given event (100) given the current population (10m), yields a PPSL of (2000*100/10) = 20,000 people interested in attending that event.

Resource

Any finite architectural component or property or behaviour that is subject to exhaustion or which can become a bottleneck to system performance. Resources are the primary focus in designing for scalability. The resource-based approach to highly scalable design involves removal of barriers to massive replication of resources, in conjunction with providing a massively scalable access mechanism for concurrent acquisition of those resources. The potential scalability of a system is however limited by additional factors, especially interdependency of resources, secondary resource exhaustion, etc.

Examples: client-server bandwidth, agent pool depth, database access mechanism, locks, transaction times, utilities, services.

Scalability

The ability of a system to grow effectively in a given dimension in proportion to the amount of resource or capacity provided. The given dimension is often associated with a related dimension. A specific system may attempt to be scaled by adding resources, but this is effective only if the system is scalable. If a system is not scalable then adding more resources will not scale it, and may even descale it further. Example: scalability in the number of avatars at an event, viewed against the size of the user population, in proportion to the hardware allocated.

Source of Viewpoint

No existing sources for this viewpoint have (yet) been sought. This viewpoint is however highly reusable, and therefore existing sources are very likely to exist and should be investigated.

Sub-VAGs that wish to reuse this viewpoint are required to specify the extent of reuse through inclusion and exclusion.

General concerns addressed by this viewpoint

The foregoing scalability viewpoint is founded on a few broad concerns:

• That all important dimensions of scalability be identified, to avoid costly surprises further downstream.
• That identified dimensions of scalability be grounded in fact and basic arithmetic as far as possible.
• That end limits of scalability be accompanied by well-reasoned near-term and mid-term projections.
• That scalability of the architectural design be accompanied by concrete proposals for achieving it.
• That all proposals are subject to effective scalability analysis and ceiling estimation.
• That design costs and impact on other VAGs and aspects of the project be assessed.
• That the concerns expressed in this viewpoint be addressed in a conformant system architecture.

Dimensions of scalability

Like an incoming tide, the pressure of population growth is unstoppable (short of business throttling or termination), and therefore most discussion of scalability centers around population-related issues. However, these are not the only ones that matter, so here we also list other significant dimensions of scalability of relevance to Second Life and other virtual worlds, for subsequent examination.

Scalability with respect to population growth

The following 4 population-related dimensions of scalability are captured from Project Motivation as an initial basis for this VAG. The estimates in dimensions 1-3 and the PPSL/MFSL (see our glossary) numbers are likewise only an initial basis:

1. Scalability of world extent:

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

2. Scalability of world population:

   • 2 billion users (rationale for initial estimate required)

3. Scalability of concurrent users:

   • 50 - 100 million concurrency across all client types (rationale for initial estimate required)

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

   • PPSL: 20 thousand per region (calculated proportional to world population)
   • PPSL: 100 thousand per region (calculated proportional to concurrent users)
   • MFSL: analysis to be done

Specific concerns within this viewpoint

Here we define the specific concerns relevant to each dimension of scalability:

Organization

Joining

Anyone with an interest in this Viewpoint is welcome to join. You should join the AW_Groupies group in Second Life.

In world meetings

We meet once a week in-world and more if people are available.

Also members are active on the wiki and in the SLDEV mailing list.

Meetings Schedule:

Meeting Agendas

• TBD

Chat Logs

• TBD

Architectural Descriptions/Views used to express this viewpoint

This section identifies:

1. the general form or representation of ADVs required to express the viewpoint
2. the elements within such ADVs which will be used to express the viewpoint
3. how these elements within such ADVs map to the concerns of this viewpoint
4. the traceability to viewpoint concerns required for conformance with the viewpoint.

None decided.

Tools employed by this VAG

• Normal wiki textual and graphic representations are expected to be sufficient for this VAG.
• Programmed tools are expected to be developed for scalability testing and measurement. See Multi-Process Client VAG -- draft.

VAG wiki structure

There is a balance to be found between excessive length of pages and excessively fine partitioning. This VAG is a technical one, which means that cohesiveness of subject is especially important, and partitioning should be driven mainly by the need for clarity rather than by simple length. Suggestions for improving partitioning under pressure of growth (highly on topic here) are very welcome, including but not limited to sub-VAG devolution.

Members (Stakeholders)

Please note that the Scalability VAG is a non-hierarchical VAG in every respect, without exception. Any tags supplied with names are purely informational. Stakeholder ordering is alphabetical.

Finrod Meriman 16:42, 17 November 2007 (PST) - Distributed systems researcher

Jesrad Seraph 04:07, 12 November 2007 (PST) - per-resident sim scale approach advocate

Morgaine Dinova 02:21, 18 October 2007 (PDT) - Founder, analyst

Zha Ewry 07:57, 25 October 2007 (PDT) - Middleware and core architecture scalability, WEB scale approach advocate