Possible solution to region scalability

Pardon me if this has been discussed before, but I believe I have a novel solution to the region scalability issue; where a region becomes unuseable after a certain (rather low) number of visitors visit the same space.

The solution is to give personal control to who he/she/it wishes to have viewable in that particular region. Let's say there's a limit of 40 visitors at a time. You can choose that the 40 visitors you can interact with be either all 'buddies', 'residents', 'strangers', or some specified percentage of each chosen at random in the case of a 'full region'. Everybody else is invisible and will not be rendered in your viewport; though they might otherwise occupy the same space at the same time.

You might also choose to wander the planet completely alone or with a single friend - but that's maybe best left as a feature enhancement for later. I bring it up to show the potential.

The chief technical issue is that one person may be interacting with a different subset of visitors than another person he/she/it is interacting with and providing a way to alleviate these problems. Or like the AOL chat rooms of several years ago, you just let each viewport fill up with the maximum allowed number and ignore the friendship and resident parameters, but I think that the ability to visit a place only with friends or locals hanging about is compelling enough to warrant consideration.

While this addresses viewer scaling quite well (in fact as I recall there is already a knob in the viewer for max viewable avatars), please explain how it applies to region (simulator) scaling. The simulators still have to compute physics for every avatar present, even if the avatar isn't visible from your viewport, in addition to all the other tasks that have to be carried out for each agent connected to a simulator.

The whole point is to change things such that the user has final control over which avatars are rendered, up to a predefined maximum. If the avatar doesn't exist in your viewport, for all intents and purposes, it doesn't exist in this space at this time.

Still doesn't effect the simulator.

You're right. It doesn't decrease server load. But that isn't important in the scheme of things. If the number of visitors to a region is limited, the economy of that region is also limited. If you remove that limitation, more money is being spent per unit time per square meter, which presumably will allow the Lindens to buy some (a lot) more hardware.

I find it surprising if the servers are doing all this computation anyway - it should all be pushed out to the client side if that's the case. The servers ideally should just be executing a handful of SQL queries based on current location and activity state and spewing out the results.

It's in the DB architecture where the rubber meets the road on scaling, but that's always been the case. Once you get past a couple million users, there are only a few possible implementations that work. I think we're already past that point.

The trick is keeping users, and that can only be done by removing limitations to the economy - so that everybody can make more money. There are two fundamental problems with the economy and this is one of them. I've addressed the other elsewhere.

The client cannot be trusted, due to hacking of the code when it was closed. Now with the client open-source, security is impossible in the client. Therefore for fair and honest transactions of any sort, all processing MUST occur on the server side.

Physics cannot be distributed out to each client. What if one client disagrees with the collisions that other client thinks should be occurring? What if one client is lagging out? Should everyone else drop to a crawl because that client is having connectivity problems?

No, physics processing and object-to-object collisions and tracking must all be done on the server. It cannot work any other way.

Client: "My agent's bullet just hit you and you and you and everyone else in the sim for...6000% damage."

Me: WTF?

The arguments to this idea have been centered around server complexity. So let's back up one step and consider the simple case - a variation of the old AOL chatroom model. There they got a certain number of folks in a room and started a new room whenever the first one filled up. The only difference here is that there are objects in the room as well as visitors. So after the area fills with visitors, you spawn off a new area. Still the same area, but a parallel universe if you will. The server only needs to apply physics to the objects that are present in that space. The other visitors are in another space - perhaps even on another server. It's just that they all happen to be occupying the same grid coordinates.

Anyway I'm not claiming this is easy to pull off. I think it will take a lot of work. But in the final analysis something along these lines has to be done or the economy which is driving SL growth will hit a ceiling. This is a business issue. If I can only sell product to (say) 100-200 people an hour maximum because of the technical limitations, I'm not going to invest a lot of resources into into my online store. There's only so much profit that can be made. If I can sell product to potentially millions of people simultaneously, that's some serious incentive. This is precisely what caused the web explosion of ten years ago. Here it's only a matter of finding a solution to the technical limitations. Bumping into 20,000 other customers at a store isn't realistic. But there's no reason why there can't be 20,000 people buying stuff at a single grid coordinate.

Ah la D&D Online.
It's not new.
I've suggested it in various threads about 12 times.

Ok, what I've actually suggested is that the sims be moved around such that the amount of resources they currently need is available: by shunting it off to a server blade with fewer sims running on it so that it gets more of the resources. A sim not needing many resources gets shunted to a blade running 14 other sims that also are not needing many resources.
Maximize the useage of all blades all the time.
(D&D Online works like this, but because players can't change the world, instances of locations are spawed and killed as required to balance load between instances of the same location)

You can not run a virtual world like SL in the way you are suggesting. What if I am a land owner who is editing my build when the world divides? Which side do I end up, where do my changes after the divide go, and what happens when the two instances "remerge" (or one ceases to exist)?

SL can also NOT be run like WoW where there are 5292526947000000000000 severs that are all the same--because SL is one large integrated world, and any change I make to a build must be seen by all other players.

So you're saying the architecture is flawed and that it won't scale. This is my entire point. So does one make changes to the architecture so that it will scale, or just throw up their hands and say it can't be done?

In the case of an owner editing the build, those resources are shared. They should show up on every viewport. It is only the visitors, their adornments and interactions which are unique to a particular viewport.

If it can't be done, then I guess big business will just walk away; and some competitor comes along that figures out how to do it right, and then the entire user base walks away. Oh well.

And at what point did you read and respond to my suggested alternative?

Making a "sharded" place that creates new shards as old ones fill up, such as on Everquest 2, imposes a burden on the user to figure out which one to use, and also can cause problems if you visit a store with a friend but you end up in one sharded instance and they end up in the other.


There is a simple solution to your problem that already works with the world as it is now: the franchise.

If you go to New York City, is there one huge McDonalds covering several blocks supplying the entire city? No, there are many small restaurants all over the city.

So build many stores with your wares, to distribute the user load across many different sims across the landscape. The stores can be strategically placed around the world such that a user can fly to your stores with ease if they wish.

.

Draco, the issue isn't with server performance. Even if you had an order of magnitude better processing ability everything would still break down, but maybe at a higher load than today. It becomes a social problem if you have to deal with hundreds or perhaps thousands or millions of players interacting in a given target space. Providing alternate viewports of that space with reduced numbers of players is the only way I can think of to increase the population density per sim at any given time in an unlimited fashion. If there's a better or simpler way, fine. I'm all for it.

And Scalar, yes I agree that franchising is an option. It's an expensive option, and you would likely be challenged to run cash flow positive at any given location. You're limited not just with the number of visitors to your shop, but the number of visitors to all locations on the same sim. You might be able to go cash flow positive if you're number one in the adult toy market and own the entire sim, but everybody else is going to be paying out pocket money to keep their storefronts alive. That might work for a little while, but eventually economic reality will catch up. It's a virtual world, but it is funded with real money, and the rate of return on that money is severely limited.

Since it seems that nobody else seems to share in a vision of an infinite economy except perhaps VC's and/or shareholders, I'll bugger off. They'll be taking their own pocket money off the table soon enough.

It's not "we can't address the scalability issues", it's "this doesn't address the scalability issues".

Crunchy, you're assuming that client scalability is the issue with many avatars. I believe it's not the case; it's the server that bogs. For example, in a full sim, scripts tend to run slowly. Scripts run on the server, not the client. There are a number of other indicators that this is the case. Try control-shift-1 and examine the data, if you're interested in a lot more info.

Cheers,
Jeff

Indeed. The biggest impact avatars have on the sim, most places, is simply the cost of streaming data over the network to the avatars. The best fix for that is to reduce scripts that update state sim-side (like physically or non-physically moving objects) and replace them with client-side effects (like particle systems, animated textures, and llTargetOmega rotations).

Sharded or not, someone has to pay for these extra shards you speak of. If you are super-popular, and you need 20 shards of your store running, who pays for those 19 additional sharded simulators? The processing power is not free for your taking.

If your store is at low traffic in the middle of the night, those 19 shards are not needed. But at the same time they likely cannot be utilized by anyone else either. Who pays to keep these spare shards running when you don't need them? Who pays for the power and physical hardware? Do you believe that since you aren't using it that this unused processing power should not be your responsibility?

The fact is, whether or not you need 20 shards running at once, you will need to be responsible for paying for the servers supporting those shards, as well as paying to support them even when you aren't really needing them.


So you say that paying for multiple islands or multiple locations is hideously expensive? I do not see how 20 islands will end up costing you any less than paying for 20 sims to support your stores in the world as it is now. By your own reasoning, you will be cash-flow negative either way from paying for all those shards/sims.

.