11.09.2017, 20:32
(Dieser Beitrag wurde zuletzt bearbeitet: 11.09.2017, 20:43 von Mareta Dagostino.)
Für einen Stresstest brauchst du viele Instanzen, die das Testobjekt belasten aber selber möglichst wenig Last erzeugen. Für jede Instanz eine eigene VM aufzusetzen (also z.B. Docker, VMware, QEMU, ...) belastet das Testsystem unnötig.
Beispiele...
Avatarlast:
Viele Accounts (fürs derzeitige OpenSim ansteigend bis ca. 100) mit Textviewer starten und ein wenig rumlaufen lassen. Textviewer belasten das System kaum. Wie sich das inworld anfühlt, kann die Testerin oder der Tester dann mit einem grafischen Viewer beobachten.
Regionen:
Viele OpenSim Instanzen mit z.B. je 16 Regionen. Jede OpenSim Instanz braucht nur ein eigenes Verzeichnis. Die Konfigurationsdateien könnte man automatisiert erstellen, dass es keine Port- und Koordinatenkonflikte gibt. Auf schöne Namen und Landschaften kommt es ja beim Test nicht an.
Inworld:
Nacheinander OARs laden mit jeweils doppelt so vielen Prims, Meshes, Texturen. Problematisch sind die Texturen, die ja unterschiedlich und in Sichtweite sein müssen um zusätzliche Last zu erzeugen. Prims und Meshes kann man mit einem Script beliebig vervielfachen, also ein Objekt aus z.B. 10.000 Prims ins Objektinventar nehmen und per Script in einer Schleife im Minutentakt rezzen. Dabei die Z-Koordinate jedesmal ein paar Meter höher legen und die Primzahl in den Chat rufen. Auch das kann dann mit einem Avatar inworld beobachtet werden bis zum Crash.
EDIT: Abschließend ist natürlich auch wichtig zu überlegen, was die Zielsetzung für den Test ist. Also die Frage, ob OpenSim das Testobjekt ist oder der Rechner, wo es drauf läuft. Soll die Performance von OpenSim getestet werden, muss der Testrechner sehr leistungsstark sein, damit wirklich die Software und nicht die Hardware den begrenzenden Faktor darstellt. Will man hingegen den billigen VServer aus der Sonderaktion testen, ob er für die eigenen Bedürfnisse gerade noch reicht, wird das Setup anders aussehen (eben eine Simulation der eigenen Bedürfnisse, dann vielleicht das Doppelte davon um zu sehen vieviel "Luft" noch ist.)
Beispiele...
Avatarlast:
Viele Accounts (fürs derzeitige OpenSim ansteigend bis ca. 100) mit Textviewer starten und ein wenig rumlaufen lassen. Textviewer belasten das System kaum. Wie sich das inworld anfühlt, kann die Testerin oder der Tester dann mit einem grafischen Viewer beobachten.
Regionen:
Viele OpenSim Instanzen mit z.B. je 16 Regionen. Jede OpenSim Instanz braucht nur ein eigenes Verzeichnis. Die Konfigurationsdateien könnte man automatisiert erstellen, dass es keine Port- und Koordinatenkonflikte gibt. Auf schöne Namen und Landschaften kommt es ja beim Test nicht an.
Inworld:
Nacheinander OARs laden mit jeweils doppelt so vielen Prims, Meshes, Texturen. Problematisch sind die Texturen, die ja unterschiedlich und in Sichtweite sein müssen um zusätzliche Last zu erzeugen. Prims und Meshes kann man mit einem Script beliebig vervielfachen, also ein Objekt aus z.B. 10.000 Prims ins Objektinventar nehmen und per Script in einer Schleife im Minutentakt rezzen. Dabei die Z-Koordinate jedesmal ein paar Meter höher legen und die Primzahl in den Chat rufen. Auch das kann dann mit einem Avatar inworld beobachtet werden bis zum Crash.
EDIT: Abschließend ist natürlich auch wichtig zu überlegen, was die Zielsetzung für den Test ist. Also die Frage, ob OpenSim das Testobjekt ist oder der Rechner, wo es drauf läuft. Soll die Performance von OpenSim getestet werden, muss der Testrechner sehr leistungsstark sein, damit wirklich die Software und nicht die Hardware den begrenzenden Faktor darstellt. Will man hingegen den billigen VServer aus der Sonderaktion testen, ob er für die eigenen Bedürfnisse gerade noch reicht, wird das Setup anders aussehen (eben eine Simulation der eigenen Bedürfnisse, dann vielleicht das Doppelte davon um zu sehen vieviel "Luft" noch ist.)