Home

 

Download

 

News

 

Support

 

Admin

 

Dev

 

Screen Shots

 

Grid List

 

Bugs

Languages:

English    Deutsch    Français

Introduction

OpenSim performance is a very complex issue. Performance can be affected by any number of things, including the number of prims on a region, number of regions, number of avatars, network quality between server and viewer, network quality between simulator and grid services, etc.

Hardware Requirements

Unfortunately, this is a very difficult question in light of all the factors mentioned above. Below are some examples of hardware people use/have used. Please feel free to add to the list, or to add any reports to the performance studies and blog posts section. These are examples to help you in your selection, not necessarily recommendations.

Object Parts ~= # prim

Sensors and Timers are generally more intensive then regular scripts, so please specify quantity of each.

Performance studies and blog posts

These provide some interesting data on the performance limitations of OpenSim at various points in time.

• https://lists.berlios.de/pipermail/opensim-users/2010-August/005189.html - Some interesting information from Mr Blue. Physical objects and max avatars are limited by single thread performance in OpenSim.
• http://www.sciencesim.com/wiki/doku.php/vwperf/start - Links to ScienceSim performance studies, including some very recent ones.
• Improving Performance - An old page from July 2009 detailing some performance issues on OpenSim. Some of these issues are still valid (e.g. ODE issues).
• NHibernate Performance Testing — SQLite and MySQL performance tests with NHibernate.
• LibSecondLife performance problems - Another old page from November 2007 detailing issues with libsecondlife (now called libopenmetaverse).
• Experiences from Operating a 3D Region Server in OSGrid - Part 1
• Experiences from Operating a 3D Region Server in OSGrid - Part 2

Performance hints

Here are some specific things you might be able to do to improve performance

Home Based systems

The most obvious performance difference between a home based cable/dsl system and a "commercial" server is the upload bandwidth. A typical home system allows 100Kb/s upload with 12Mb/s download, a "commercial" system typically has a "symmetrical" bandwidth of say 12Mb/s UP AND DOWN! "Commercial" systems can essentially buy unlimited bandwidth as needed, but it does get expensive to buy bandwidth that you don't need!

In practice this limits the number of "external" users on a "home system" to 4 or 5, but LAN users (NPCs/bots etc.) are essentially unlimited.

A reasonable strategy (i.e. MY strategy) is to use the home system for experimentation and then move the entire sim to a "commercial" VPS service if the sim gets popular (and produces enough $$$ to pay the freight!)

Running Squid on your region server as a reverse proxy to the asset server

1. Download and install the Squid Proxy from: http://www.squid-cache.org/Download/
2. Create your squid.conf configuration file.
3. Change your asset_server configuration in your OpenSim.ini to point to http://localhost:3128/
4. Start everything up!

Now assets will be cached in the squid cache on the region server, and will be served up much faster, especially on region restart.

GC_NO_EXPLICIT

Sometimes this patch applied to mono-svn has helped my sim run a lot faster and not slowly get bogged down.

$mono-svn-root$/mono

 mono/metadata/boehm-gc.c

Index: boehm-gc.c
===================================================================
--- boehm-gc.c	(revision 105684)
+++ boehm-gc.c	(working copy)
@@ -107,6 +107,10 @@
 void
 mono_gc_collect (int generation)
 {
+	static int no_explicite_gc = 0; if (no_explicite_gc==0) {if (getenv("GC_NO_EXPLICIT")) {no_explicite_gc = 1;return;} else {no_explicite_gc = 2;}} else if (no_explicite_gc==1) {
+		g_print("\n --------GC_NO_EXPLICIT \n");
+		return;
+		}
 	MONO_PROBE_GC_BEGIN (generation);
 	
 	GC_gcollect ();

Not only this, but I recompile the mono runtime:

--with-large-heap=yes

Otherwise, the Sim is limited to 3GB RAM. Probably, this second peice is more important. But still, afterwards it's worth a shot to test with both to see if there is a difference in performance:

export GC_NO_EXPLICIT=1

and

unset GC_NO_EXPLICIT

What I think, (only a guess) is that Mono starts internally GC thrashing in fishing expeditions to gaining maybe 1k of RAM at time. And by having a large heap (>3GB), it is possible might keep mono less apt to do stop world complete collections as often.