Performance
From OpenSimulator
m (Robot: Replacing 'OpenSim' to 'OpenSimulator', which is the precise name) |
(→Introduction) |
||
| Line 2: | Line 2: | ||
= Introduction = | = Introduction = | ||
| − | |||
OpenSimulator 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. | OpenSimulator 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 in the introduction. | Unfortunately, this is a very difficult question in light of all the factors mentioned in the introduction. | ||
| Line 165: | Line 127: | ||
|} | |} | ||
| − | == Performance studies and blog posts | + | = Software = |
| + | |||
| + | == Database == | ||
| + | |||
| + | By default, OpenSimulator is configured to use the SQLite database. This is very convenient for an out-of-the-box experience since it requires no configuration. However, it's not designed for heavy usage, so if you build very quickly or have more than a few people on your simulator then you will start to see performance issues. | ||
| + | |||
| + | Therefore, we recommend that you switch to MySQL as soon as possible. This will provide a much better experience but will take a little bit of work to set up. | ||
| + | |||
| + | There is also a database plugin for MSSQL but this is not well maintained between OpenSimulator releases. | ||
| + | |||
| + | Unfortunately, tools for migrating OpenSimulator SQLite data to MySQL are currently limited. Migration is also possible by saving OARs/IARs of your data from sqlite and loading them up once you've reconfigured to use MySQL. | ||
| + | |||
| + | == Configuration tweaks == | ||
| + | |||
| + | There are a couple of OpenSimulator configuration tweaks that you can do to significantly improve script loading performance in certain situations. These tweaks can be made in your OpenSim.ini config file. These apply to current OpenSimulator development code (0.7.3-dev) and may also apply to 0.7.2, though certainly not any earlier. | ||
| + | |||
| + | ===Set DeleteScriptsOnStartup = false=== | ||
| + | |||
| + | [XEngine] | ||
| + | DeleteScriptsOnStartup = false | ||
| + | |||
| + | This means that OpenSimulator will not delete all the existing compiled script DLLs on startup (don't worry, this setting doesn't touch the actual LSL scripts in your region). This will significantly improve startup performance. However, if you upgrade OpenSimulator in place (e.g. you regularly update your installation directly from development code) then you may occasionally see problems if code changes and your previously compiled DLLs can't find their old references. | ||
| + | |||
| + | In this case, you can either set DeleteScriptsOnStartup = true for one restart in order to clean out and recompile script DLLs or you can manually delete the relevant bin/ScriptEngines/<region-uuid>/*.dll.* files, which will force OpenSimulator to recompile them. You could also delete the entire bin/ScriptEngines/<region-uuid> directory but this would lose all persisted script state (which is kept in the <script-item-id>.state files). | ||
| + | |||
| + | ===Set AppDomainLoading = false=== | ||
| + | [XEngine] | ||
| + | AppDomainLoading = false | ||
| + | |||
| + | By default, OpenSimulator loads every script DLL into its own AppDomain. If this is set to false, then all scripts are loaded into OpenSimulator's default AppDomain instead. | ||
| + | |||
| + | This will significantly improve script startup times and reduce initial per-script memory overhead. | ||
| + | |||
| + | However, setting this to false will also prevent derezzed script DLLs from being removed from memory (only whole AppDomains can be unloaded). This might cause an OutOfMemory problem over time, as avatars with scripted attachments move in and out of the region. Whether this is a problem for you will depend on factors such as the avatar population of your grid. | ||
| + | |||
| + | In addition, Windows users have reported script loading problems with AppDomainLoading = false, though I (justincc) haven't been able to replicate this with current OpenSimulator code on my WindowsXP machine. | ||
| + | |||
| + | = Performance studies and blog posts = | ||
These provide some interesting data on the performance limitations of OpenSimulator at various points in time. | These provide some interesting data on the performance limitations of OpenSimulator at various points in time. | ||
Revision as of 15:59, 6 April 2012
Contents |
Introduction
OpenSimulator 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 in the introduction.
However, we can say that OpenSimulator does not run well when it only has access to a single CPU core - you should regard a dual-core machine as the minimum.
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.
| Description | Operating System (please add Mono version if appropriate) | OpenSimulator version | RAM/AVG_USE_% | CPU | #/type of regions | # simultaneous avs | #scripts/timers/Sensors | Location | #objectparts |
|---|---|---|---|---|---|---|---|---|---|
| hosted Xen VPS | Ubuntu Intrepid (8.10) | Unknown | 540MB/? | 1x quad-core 2.5GHz Xeon (L5420) | 1 region + 9 voids | generally 1-2 | few | Knifejaw Atoll & surrounding on OSGrid | ? |
| hosted Xen VPS | Ubuntu Jaunty (9.04) | Unknown | 360MB/? | 2x dual-core 2.0GHz Xeon (5130) | 1 void | generally 1-2 | none | Knifejaw Road on OSGrid | ? |
| Dedicated Server from A+ | Windows Server 2003 | Unknown | 1 Meg | 1x single-core 2.8GHz Celeron | 2regions per server | 6 at once with no issues | Waterfalls, texture anims, window texture switchers, lots of sound loops | Pleasure Planet Welcome center & Region Pleasure Planet in OSGrid | 20000 prims per region |
| Amazon EC2 "high-CPU medium instance" (Xen VM) | Windows Server 2003 | Unknown | 1.7GB | 1x dual-core 2.3GHz (Intel E5345) | 1 region with sailing race course | 7 avs, 4 in boats | scripted start line | Castle Rock, OSGrid | |
| Dedicated Server from simhost.com | SuSe 11.2 x64 | Unknown | 8gb / 50% | 4x Core2Quad Q9300 2.6ghz | 1 region (Wright Plaza) uses approx 4gb ram | 20-25 users | Freebie Stores / Meeting Center / Video Theater | @osgrid.org Heavy Use Sim | 17500 prims aprox 1500 scripts |
| Home machine | Windows XP SP3 | 0.7.0.1 (Diva r13558) | 3GB / 15-40% incl. Opensim and MySQL | 4x Core2Quad Q6600 2.4 GHz. Use: generally, 0-10% | 11 regions | 1-6 users | Many scripted objects (1934 scripts) | Condensation Land | 38,065 prims |
| Home machine | Ubuntu Lucid 10.04 (32 bit pae) | 0.7.0.1 (Diva r13558) | 160Mb no users, add 5Mb/user incl Opensim and MySQL | I7-920 (dual threaded quad core), 3.8Ghz, 6Gb RAM, 0-10% Load | 4 regions (Diva default config) | 1-4 users (approx 20Kb/sec bandwidth/user) | Few scripted objects (<10) | Mars Simulation- Based on Erik Nauman's Open Blackboard | 158 prims |
| Hosted Parallels Virtuozzo 4.5 | Win/Net (32 run) | 0.7.0.2 (D2) | 420Mb total, incl OS, Opensim and MySQL | i7 Quad 950 (Bloomfield) 3.07GHz, 8 Core, 2Gb RAM, 0-2% Avg Load | 16 regions (4x4 mega-region) | <6 users | vehicle scripted objects (<5) | Metaverse Sailing | <1000 prims |
| VPS | Debian Lenny 5 (mono 2.4.2.3) | OSgrid 0.7.1 (Dev) cd4d7a7: 2010-10-15 | 655MB average out of 1722MB RAM, incl. MySQL | Intel Quadcore 2.5 Ghz (1 core assigned to vps) average use: 40-45% | 20 regions | <4 users | about 20 different light scripts, but we're also experimenting with heavier HUD scripts (timers, lots of ll(Get/Set)PrimitiveParams and large lists) and custom IRC relay | Phoenix Rising Isles on OsGrid | 3727 prims |
Software
Database
By default, OpenSimulator is configured to use the SQLite database. This is very convenient for an out-of-the-box experience since it requires no configuration. However, it's not designed for heavy usage, so if you build very quickly or have more than a few people on your simulator then you will start to see performance issues.
Therefore, we recommend that you switch to MySQL as soon as possible. This will provide a much better experience but will take a little bit of work to set up.
There is also a database plugin for MSSQL but this is not well maintained between OpenSimulator releases.
Unfortunately, tools for migrating OpenSimulator SQLite data to MySQL are currently limited. Migration is also possible by saving OARs/IARs of your data from sqlite and loading them up once you've reconfigured to use MySQL.
Configuration tweaks
There are a couple of OpenSimulator configuration tweaks that you can do to significantly improve script loading performance in certain situations. These tweaks can be made in your OpenSim.ini config file. These apply to current OpenSimulator development code (0.7.3-dev) and may also apply to 0.7.2, though certainly not any earlier.
Set DeleteScriptsOnStartup = false
[XEngine] DeleteScriptsOnStartup = false
This means that OpenSimulator will not delete all the existing compiled script DLLs on startup (don't worry, this setting doesn't touch the actual LSL scripts in your region). This will significantly improve startup performance. However, if you upgrade OpenSimulator in place (e.g. you regularly update your installation directly from development code) then you may occasionally see problems if code changes and your previously compiled DLLs can't find their old references.
In this case, you can either set DeleteScriptsOnStartup = true for one restart in order to clean out and recompile script DLLs or you can manually delete the relevant bin/ScriptEngines/<region-uuid>/*.dll.* files, which will force OpenSimulator to recompile them. You could also delete the entire bin/ScriptEngines/<region-uuid> directory but this would lose all persisted script state (which is kept in the <script-item-id>.state files).
Set AppDomainLoading = false
[XEngine] AppDomainLoading = false
By default, OpenSimulator loads every script DLL into its own AppDomain. If this is set to false, then all scripts are loaded into OpenSimulator's default AppDomain instead.
This will significantly improve script startup times and reduce initial per-script memory overhead.
However, setting this to false will also prevent derezzed script DLLs from being removed from memory (only whole AppDomains can be unloaded). This might cause an OutOfMemory problem over time, as avatars with scripted attachments move in and out of the region. Whether this is a problem for you will depend on factors such as the avatar population of your grid.
In addition, Windows users have reported script loading problems with AppDomainLoading = false, though I (justincc) haven't been able to replicate this with current OpenSimulator code on my WindowsXP machine.
Performance studies and blog posts
These provide some interesting data on the performance limitations of OpenSimulator 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 OpenSimulator.
- 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 OpenSimulator. 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
