Understanding Region Scaling?


#1

Hi,

Would someone help me to understand the parameters related to the number of allowed agents per region? i.e, in SL there is a maximum of 100 agents per region. What factors determine how many avatars are allowed per region? Is that even a question? What about scalability and recreating instances of an existing place? If I don’t sound as though I know what I am talking about, well it’s because I don’t–really? However, I know what I want to know for some future planning. :smile:

Seems as though I read something that would help me understand this, however…it evades me, currently. Thanks in Advance.

In the Highest Vibration of Love
Kween


#2

At this time - the level of scaling should be much much higher than anything seen in SL/OS, but, that’s eventually, not today.

At this time there’s no easy ability to split up various server processes to work on only sub-sets of a domain’s space so your hard limit is whatever your server can handle without choking. Audio is currently fairly heavy on bandwidth so if you’re hosting on a home network with lowish upstream bandwidth you could run into troubles after 5 or so agents in domain.


#3

Our stresstest might give you a basic idea of how to make some calculations, but these things might change at any given time, we will conduct stresstests every month.

https://alphas.highfidelity.io/t/detailed-server-stress-test-results/


#4

@OmegaHeron @adin. TY.

So, eventually, when one is contemplating projects with many avatars a first and primary consideration would be serverload? Is that the relative short answer?


#5

Yes, keeping in mind that High Fidelity breaks portions of the server tasks into single instances where you can provide or, eventually, pay someone for added power based on instant need.


#6

There is no direct comparison between the SL/OpenSim geographic simulation, where a server instance handles a fixed amount of space (all the physics, all the avatar interactions, etc.) versus the HF distributed model where the simulation is broken into multiple classes of activities. The distributed approach theoretically permits multiple server instances to work on various parts of a domain, so it has immense potential scalability, though right now that is not entirely implemented. It is nice to see that the architecture is quite scalable.


#7

No, the server load seemed fine unless you spawn too many physics related objects. I’d say the server we have there could actually serve upwards of 150 people and that’s not even our production server.

But the bandwidth is the major bottleneck. It is absolutely immense, which is why i am trying to push for more optimized audio solutions.