How many avatars can OpenSim handle?

Exactly how many people can a region in OpenSim support? How many people could meet for business meetings or presentations in an OpenSim region?

Intel has a tool that allows more than 1,000 avatars on a single OpenSim region. The tool will be getting some real-life testing next year, before it is publicly released. (Image courtesy Michael Cerquoni .)

Allow me to illustrate with this piece of string and a tape measure. There are unfortunately many variables to consider, so much so that it is almost impossible to give any hard and fast rules. For example — how complex is the 3D ‘static’ environment (how many prims are there?), how many scripts are running in active objects, how many event listeners are running in those scripts? What will the people be doing – if they are constantly moving about and even crossing region boundaries, there will be a lot more load on the server to deliver new 3D data and textures whereas if they are simply sat in a chair in an office, there will be almost no strain, the only data being sent around typically being where the avatar is looking and maybe gestures (and of course voice traffic). Are the users interacting with in-world tools and obects such as display panels, noteboards or camera control objects? Finally we have infrastructure variables – what CPU is being used, how many cores, how much memory and what operating system (Windows and hence .NET or linux and Mono.)

All of this uncertainty is fine and accepted if your users are pioneers of virtual worlds, creating social spaces, playing with the technology, enjoying the feeling of being into something at the start. It may even be acceptable or at least accepted by educators who may be willing to deal with the uncertainty to get the well documented educational gains and low costs of OpenSim.

But if you expect business users to pay to use a service based on OpenSim, you need some better answers.

The only real way to find out how many avatars your environment can handle is to log lots of folk into it and see what happens. There’s nothing quite the same as a bunch of real 3D clients connected from a range of IP addresses all downloading textures and receiving updates. However, this may not be practical if you don’t have a huge team of people to hand. You can try running multiple clients yourself, but a full 3D viewer such as Imprudence or SL Viewer 2 is a heavy weight beast, even the best of PCs may struggle with more than a few client instances.

Another option is a lightweight non-graphical viewer such as Radegast. This allows you to log in, interact with objects and move about but consumes about a third the resources allowing you to run many more clients on each PC. Since it isn’t downloading the textures this most closely resembles the scenario of users staying roughly in one place, as they might for a business meeting. The next option if you are technically adept is to use libopenmv – the C# client library that allows you to write your own clients that can connect to OpenSim and SecondLife (and that underpins Radegast and OpenSim itself). This comes with an example app ‘TestClient’ which provides the ability to log an AV in and do some simple things. From that starting point, you could go on to automate the process of logging in many accounts and log the resulting stats from the sim. You could also automate some typical actions such as sitting on chairs, changing presentation slides and so on.

At the end of this process you will have some numbers. Lets say that you find that on current hardware in the environment you plan to use you start hitting unacceptable performace with 25 users logged in. What to do? If your customer only needs a maximum of 20 users you can go back to the couch, but we need an option for when they come back and say “We love it, can we have 100 people meeting at once?”. If those 100 people want to meet in the same space and all interact, then with OpenSim you may have a problem right now. However, if what you want is simply to have more people meeting in small groups, campus-like then here are two immediate options:

  • Create a grid — connect four regions each of which can support 25 users, ensure that when launching a meeting users are routed to a sim with capacity
  • Create stand alone regions — again, with intelligent routing

Currently there is no mechanism in OpenSim for limiting the number of users who can attempt to log into a region — at some point the experience will begin to degrade for users already logged in as more people join, then at some point new users may find they can’t log in or they can but everything has ground to a halt. This assumes that the route in is directly from the client. It would be nice if there was a configurable ‘max_users’ setting, resulting in a nice friendly error messages for connections above that number, maybe I should write one.

However, if you launch the viewer from your own web-client as we do then you have more options. Before starting the viewer, you could check how many users are logged in, and change the loginUri dynamically to another region in the grid. Or you could exploit a room reservation system – limit the number of users that can use each of several meeting spaces, and ensure that the total can’t exceed your known limit (say 25, 40, whatever your load testing revealed) — then effectively the reservation system is looking after the limit for you. Once all the spaces in the first region are booked, people will automatically only have the option of reserving spaces in the second region. They won’t even need to know that these spaces are in different regions if the spaces are reserved by name – “Meeting Room 1” etc. Even better, these regions could be spawned on demand since the reservation system knows in advance how they are needed and can fire them up (say on Amazon EC2) just before they are required.

Do you have experience with OpenSim hosting? How many avatars can you comfortably host on a region? Let me know, if enough people respond I’ll try to summarize the results.

(Article reprinted with permission from KnowSense Limited.)'
Latest posts by Neil Canham (see all)