Difference between revisions of "Mesh/Mesh Server Weight"

From Second Life Wiki
Jump to navigation Jump to search
Line 4: Line 4:


== Motivation ==
== Motivation ==
Different pieces of content affect server load in a variety of ways. An object that may appear simple to display and have a simple physics representation may cause significantly more load on a simulator than other pieces of content that appear more complex. Having all prims charged the same amount regardless of how much load they put on the simulator doesn't give content creators the proper feedback for optimizing their designs.
The server must track all pieces, or prims, in the region at all times. As such every individual piece, or prim, has a certain cost to the server regardless of its physical or visual complexity. There are, however, some factors that make an object more or less expensive for the server to track: in particular truly passive objects that are not scripted or physical are much easier to track than scripted or physical objects.
 
 


== Concept ==
== Concept ==
Server load from an object can be approximated by the number of messages that are generated from the object. The more object updates that a piece of content generates, the more data handling and processing the server has to do in order to keep all avatars in the area up to date with the object's current status. When prims are linked together into a single object, there are some per-object messages that need to be handled, and some per-prim messages. Additionally, some pieces of content are far more likely to generate more messages - such as scripted or physical objects
There are two basic goals for this cost:
* The maximum server load from objects should not increase from mesh content.
* Allow more passive content than before.


== Equation ==
# Take the number of prims in the object.
# If the object contains no scripts and is not physical: divide by static_bonus


== Equation ==
* ''per_prim_cost'' = 1.0<br>
# Take a base cost per object
* ''static_bonus'' = 2.0<br>
# Add a cost per prim in object * number of prims
* ''cost_scalar'' = 1.0
# Multiply by an "active" multiplier if object is dynamic (physical or scripted)


== Computing Cost ==
The ''static_bonus'' only applies if the object is not physical and contains no scripts.
dynamic_multiplier = 2.0 <br>
static_multiplier = 1.0 <br>
per_prim_cost = 0.5 <br>
base_cost = 1.0 <br>


if there are any scripts or the object is physical, active_cost = dynamic_multiplier. Otherwise active_cost = static_multiplier.
Server weight per prim: ''cost_scalar'' * (''per_prim_cost'' / ''static_bonus'')


Cost scaler is currently 1.0
== Examples ==
{| border="1" cellpadding="3" cellspacing="0"
! align="right"| Prims
! Scripted Or
Physical
! Server
Cost
! Non-Mesh
Cost
|-
|align="right"|1
|align="center"|No
|align="right"|1
|align="right"|1
|-
|align="right"|1
|align="center"|Yes
|align="right"|1
|align="right"|1
|-
||||||||
|-
|align="right"|10
|align="center"|No
|align="right"|5
|align="right"|10
|-
|align="right"|10
|align="center"|Yes
|align="right"|10
|align="right"|10
|-
||||||||
|-
|align="right"|30
|align="center"|No
|align="right"|15
|align="right"|30
|-
|align="right"|30
|align="center"|Yes
|align="right"|30
|align="right"|30
|}


Server weight(per prim) = cost_scalar * (active_cost * (per_prim_cost + base_cost / num_prims)
== How To Optimize ==
* Consolidate mesh shapes such that the individual uploaded meshes are as complete as possible.
** A more complete mesh will generally have a streaming cost of several PE and not be server bound.
* Separate static content from dynamic content when possible.

Revision as of 16:03, 5 August 2011

READ THIS FIRST

This is a preliminary design of an unimplemented cost algorithm. EVERYTHING is subject to change, and certainly will change, during the course of implementation.

Motivation

The server must track all pieces, or prims, in the region at all times. As such every individual piece, or prim, has a certain cost to the server regardless of its physical or visual complexity. There are, however, some factors that make an object more or less expensive for the server to track: in particular truly passive objects that are not scripted or physical are much easier to track than scripted or physical objects.

Concept

There are two basic goals for this cost:

  • The maximum server load from objects should not increase from mesh content.
  • Allow more passive content than before.

Equation

  1. Take the number of prims in the object.
  2. If the object contains no scripts and is not physical: divide by static_bonus
  • per_prim_cost = 1.0
  • static_bonus = 2.0
  • cost_scalar = 1.0

The static_bonus only applies if the object is not physical and contains no scripts.

Server weight per prim: cost_scalar * (per_prim_cost / static_bonus)

Examples

Prims Scripted Or

Physical

Server

Cost

Non-Mesh

Cost

1 No 1 1
1 Yes 1 1
10 No 5 10
10 Yes 10 10
30 No 15 30
30 Yes 30 30

How To Optimize

  • Consolidate mesh shapes such that the individual uploaded meshes are as complete as possible.
    • A more complete mesh will generally have a streaming cost of several PE and not be server bound.
  • Separate static content from dynamic content when possible.