As opensim and realxtend get mature , the question about
stability of certain versions and resource usage become a daily
question. People tend to invite other friends to take
measurements, which leads to unpredictable load due to as
unpredictable user behavior. I want to give a short overview
on tools and interpretations, as used by me and my crew.
Traffic measurement
For network traffic, ntop is used. Ntop is available on *nix
and Windows.
To show only the relevant protocols used by Opensim, an own
protocol definition file is used and the traffic is filtered to the
IP running the simulator. Ntp is started using the "-p
protocol.def" option.
The protocol definition file used is:
Forbidden=telnet|snmp
http=www|https
ftp=ftp|ftp-data
DNS=name|domain
email=smtp|pop3
admin=22|3000|10000
opensim=9000-9200
opensim-grid=8000-8006
As well, people use different tools and interpretation even of
basic numbers, e.g. count avatars on a visual basis - which
includes crashed viewer as well.
By that, you get own graphics for opensim traffic.
Memory usage
For memory usage, we always use the "show stats" command from
inside the viewer, as well as the operating specific statistics on
the individual task.
Remeber that watching the memory groth by monitoring the "free
memory" does not make sense on unix systems, and not on any system
running a database system because they will cache data to RAM.
Make sure that you compare similar situations - so a sqlite
maybe slower, but MySQL has more overhead in RAM for the RDBMS
system and cache.
Simulator data
A nice source for simulator data is the webstats we have had a
while already:
If it comes to agent count, frames per second etc - you can use
the "statistic bar" from inside the viewer.
Getting enough agents
For agent simulations you will typically need "agents on
demand". Sometimes it will be pure agents connections,
sometimes agents using physics (jumping, running) and sometimes
full agents (full influence of viewer settings on graphics).
For all kinds I advice to have dedicated accounts instead of
using the auto-name option and disabling authentication. If
you test on a grid, you will need regular accounts anyway. Always
find out beforehand that such testing is allowed in the grid in
quest and you do not influence other peoples resources. Make sure
the owner of the Agent is reachable by email, e.g. open enough
email accounts wich are forwarded.
Basic agents
For basic agents, i use the libsl "Testclient". You can still IM (by right
clicking the avatar) individual avatars to clone yourself, move, tp
or follow yourself - or each other. If you just log them on, they
will not move - so that's a very basic load test.
Physic agents
If you prefer to test the physics engine, you need moving
agents. Opensim does bring the "pCampbot" for that usage. It seems
based on the libsl client, but runs, jumps and bumps others - as
well as they can talk. This is kind of a real stress test.
Scripting
Bringing 20 agents in manually is time consumptive - so I
decided to script this. While my productive server are usually
Linux - the desktops are Windows. But i guess you can adopt the
very simple idea easily.
Given agtent that have the same first name (Test) and a last
name that is just appended by a number (Fisch1 , Fisch2) and all
use the same (complex!) password, this script was builded. It
should have a delay for each login and not require any
aditional tools. It is no high end and can pe improved in many ways
- it´s enough for me and i want to share the idea.
Client-Start.cmd
ping -n %1 127.0.0.1
TestClient.exe -first Test -last Fisch%1 -pass
Your2compleXpw -startpos %2 -loginuri http://osgrid.org:8002/-masterkey
%3
REM pCampBot.exe -firstname Test -lastname Fisch%1
-password Your2compleXpw -startpos %2 -loginuri http://osg
rid.org:8002
Client-Test-run.cmd
@echo off
echo Infomation inside this file
REM multi testclient launch
REM provide 3 infos while start:
REM number of clients - location to start
- master avatar UUID
REM client-test-run 3 "Sharkland testing/128/128/25″
29bdd4c2-31ac-45b6-9fd6-7ec37797ba89 launches 3 avatars at
Sharkland with Ralf Haifisch as master
FOR /L %%I IN (1,1,%1) DO START "Test Fisch%%I"
Client-Start.cmd %%I %2 %3 < client-command.txt
Client-Test-run.cmd is called with 3 parameter (number of
clients, login location, UUID of the master avatar who is allowed
to command)
Client tes run starts as many new cmd-boxes as needed via
calling Client-Start.cmd
Client-Start does ping the local computer as often, equalie
to the count for the individual cmd-box as a delay wich builds
a login sequence.
You get help via IM to the client or in the local command box
via "help".
Full agents
For full agents, i did not find an alternative to using several
computer running e.g. Hippo Viewer, as it is possible to start
Hippo several times (even without a command line option), so you
can have 2-3 agents per computer. Remember that this full agents
will use huge amount of bandwidth, as well as RAM/CPU/GPU. So the
test results are somewhat depending on you resources
--> TIP: to make your testkit portable, maybe use
amazon S3 as a drive. You can easly connect it to Linux and
Windows, e.g. via jungedisk. Togehter with amazon EC2 images,
you allways have enough power by computer and internet connection
means.
Test setup
While practical expediences may lack some detail data, you
should always try to collect and report some common environment
descriptions:
- Hardware type (VPS, root server, CPU´s, Disc-queue or
system)
- RAM (if you have "boostable" RAm clearly seperate this from
assured RAM)
- Operating System , Version
- MONO or .Net version
- Bandwidth to the Internet, maybe even latency to central
server
- Version of simulator tested
If you prepare a test, try to think what the numbers should
explain. Define the test cases before actualy running the test
- so you just need to fill in the actual numbers. Don´t
modify test setting "on the go". The test results should
include a protocoll in chronological order. Repeatable results
are great, but a collection of well done reports on practical
expiriences like script load, party etc are a good basis as
well.
cheers,
Ralf