eMail
 Suche
 Impressum

Subsections


7. Performanzmessungen

Im vorliegenden Kapitel soll erläutert werden, wie die vorgestellte Implementierung auf Performanzkriterien geprüft wurde. Zur Erleichterung dieser Aufgabe wurden einige Skripte entwickelt, die automatisierte Clients auf fernen Rechnern starten können.

7.1 Tests auf DSL-System

Das System wurde in der in Abbildung 7.1 gezeigten Konfiguration entwickelt und ständig nebenbei getestet. Dabei wurde auch auf diverse freiwillige Testpersonen zurückgegriffen, die über die DSL-Anbindung aus dem Internet an das System angeschlossen waren. Die plattformübergreifende Lösung in Form eines ausführbahren Java-JARs machte es Anwendern leicht, die Demo zu starten.
Figure 7.1: Verfügbare DSL-Testumgebung
Image test_env

7.1.1 mit realen Spielern

Über Wochen hinweg wurden mit mehreren Spielern aus dem Internet Testspiele absolviert. Die Performanz des Systems war bei allen Tests lediglich durch die Netzwerkbandbreite des RegionControllers in Richtung Internet limitiert.

Ein verbundener Client verursachte einen Verkehr von ca. 10 KByte/Sek., was angesichts meiner DSL-Anbindung mit einem Upstream von 64KByte/Sek. die Anzahl auf etwa 5 Clients beschränkte. Darüber hinaus ruckelte das Spiel spürbar, denn die anfallenden Datenmenge konnte nicht mehr vor dem nächsten Tick übertragen werden. Einige BotPlayer konnten zusätzlich zu den menschlichen Spielern in das Spiel eintreten, da diese die internetseitige Bandbreite nicht schmälerten.

7.1.2 mit BotPlayern

Für automatisierte Tests habe ich eine Klasse BotPlayer (Details siehe Abschnitt 6.1.5) implementiert, die einfache Spielzüge ausführt und gelegentlich auf Objekte feuert. Somit kann durch solch einen Bot ein einzelner Client simuliert werden.

Bei Leistungstests auf dem Rechner ``media'' 7.1 wurde etwa mit 20 BotPlayern die Leistungsgrenze der CPU erreicht. Wurden weitere BotPlayer gestartet, dann konnten einige RegionControllerThreads die Ticks nicht mehr zuverlässig berechnen.

7.2 Tests im Rechner-Pool

Der Fachbereich stellte einen Zugang zu diversen Pool-Rechnern zur Verfügung. Diese konnten für einige Stabilitäts- und Skalierungstests genutzt werden. Die Ergebnisse sollen hier zusammengefasst werden.

7.2.1 ServerStats

Wie im Abschnitt 5.5.9.1 beschrieben, wird ein ServerStats-Protokoll angefertigt. Das Protokollierungsinterval wurde auf 2000ms gesetzt, um den Verlauf der Werte in einer hohen Auflösung darstellen zu können. Eine grafische Auswertung dieser Daten wurde mit Gnumeric [10] erzeugt.

7.2.2 Grundsätzliche Vorgehensweise

Die Performanztests werden nach folgendem Schema durchgeführt.
  1. Auf dem Server wird der Server-Prozess des MmpgP2P-Systems gestartet. Somit läuft hier auch der initiale RegionController. Die Spielewelt wird mit einer Tilesize von 2000 konfiguriert und hat die Größe 200.000x200.000.
  2. Als Clients für das System kommen Prozesse auf acht Pool-Rechnern im LAN zum Einsatz. Zunächst werden auf jedem dieser Rechner über ein Skript (siehe Abschnitt 7.2.3) zwei BotPlayer mit RegionControllern auf den Ports 18900 und 18901 gestartet. Somit stehen dem Server 16 freier RegionController auf verschiedenen Rechnern zur Verfügung. Der BotPlayer führt automatisierte Spielzüge durch und simuliert somit einen aktiven Client.
  3. Als nächstes werden kontinuierlich zusätzliche Clients simuliert, indem erneut auf jedem der Pool-Rechner ein weiterer BotPlayer gestartet wird. Dies wird so lange fortgeführt, bis die Pool-Rechner nicht mehr in der Lage sind, weitere Prozesse zu starten. Jeder vierte BotPlayer wird mit einem RegionControllerThread gestartet, die übrigen mit dem Parameter $--$norc.
    Dieser Schritt wird so lange wiederholt, bis der Server nicht mehr performant läuft oder ein schwerwiegener Fehler auftritt, der das System zum Absturz bringt.

7.2.3 Skripte zum Starten der Clients

Um das Starten von Clients zu automatisieren, wurden Sktipte entwickelt, die verschiedene Aufgaben übernehmen.
  • startManyClients.sh
    Per SSH wird eine Verbindung zu jedem Pool-Rechner aufgebaut und dort das Script startBots.sh aufgerufen (siehe folgender Abschnitt 7.2.3). Ein Paramter $--$rcport sollte bei einem Aufruf mit angegeben werden, damit auf den Pool-Rechnern mehrere RegionController starten können.7.2

  • startBots.sh
    Dieses Skript wird über ssh auf verschiedenen Pool-Rechnern aufgerufen. Es kümmert sich darum, dass ein BotPlayer mit einer zufälligen Verzögerung zwischen 1 und 60 Sekunden startet und zum Server verbindet. Hängt man den Parameter $--$norc an, dann startet der BotPlayer keinen RegionController.

    Mit dem Parameter $--$nr kann man dafür sorgen, dass mehrere Instanzen von BotPlayer innerhalb einer Java-VM 7.3gestartet werden. Ein zusätzlicher Parameter $--$interval kann zum Festlegen eines Intervals (in Millisekunden) zwischen zwei zu startenden Instanzen genutzt werden. Standard sind 10 Sekunden Wartezeit zwischen zwei Instanzen.

    Um nur eine gewisse Anzahl an RegionControllerThreads zu starten, benutzt man den Parameter $--$rcnr. Dann werden so lange BotPlayer mit RegionController gestartet, bis dieser Wert erreicht ist. Der Port, auf dem der jeweilige RegionController bindet, wird dabei bei jeder Instanz um eins erhöht, ausgehend von dem konfigurierten Port.

    Einige Poolrechner konnten bereits nach dem Start von ca. 20 BotPlayern nicht mehr genügend Rechnenleistung für weitere BotPlayer aufbringen. Eine Verbindung per SSH war nur noch nach einer Wartezeit von bis zu einer Minute möglich. Daher wurde in der Socket-Verarbeitung ein Befehl KILL eingebaut. Verbindet man sich mit telnet auf einen der von BotPlayer gestarteten Threads und gibt KILL ein, dann wird über System.exit() die Java-VM beendet. Damit kann man blockierende Prozesse schnell beenden.

7.3 Auswertung der gesammelten Daten

Die gesammelten Statistiken (siehe Abschnitt 5.5.9.1) wurden mit Gnumeric [10] zu Diagrammen zusammengefasst. Es folgen einige Diagramme, die das Verhalten des Systems skizzieren sollen.

7.3.1 Erste Testreihe

Die Spielewelt wurde auf 200.000x200.000 Punkte mit einer Kachelgröße von 2000 eingestellt. Zur Befüllung der Welt wurden 2000 statische und 1000 bewegende Objekte eingefügt. Das Client-Limit pro Region wurde auf 20 eingestellt.

BotPlayer wurde angewiesen, 28 Clients und 4 RegionController pro Pool-Rechner zu starten. Dies kann man in den folgenden Diagrammen nachvollziehen. Zwischen zwei Client-Starts werden 20 Sekunden vergangen gelassen.

7.3.1.1 Verbundene Clients und Auslastung

In Abbildung 7.2 sind drei wichtige Kurven zu sehen. Zum einen die Anzahl der mit dem System verbundenen Clients (clients) und zum anderen die Systemlast (load*5). Die dritte, oberste Kurve (conns) gibt die Anzahl der bisher eingegangenen und verarbeiteten Verbindungen an. Diese Zahl enthält Login-Verbindungen eines Clients sowie regelmäßige Verdingungen der RegionController.
Figure 7.2: Testreihe 1: Anzahl verbundener Clients, Anzahl totaler Verbindungen zum Server sowie LoadAvg (um den Faktor 5 gestreckt)
Image clients_cpu
Während die Anzahl an Clients stetig zunimmt, bleibt die Systemlast auf einem moderaten Level. Die Auslastung des Servers skaliert gut mit der Anzahl verbundener Clients. Über den weiteren Verlauf der Kurve bei deutlich mehr als 200 Clients lassen sich jedoch keine weiteren und verlässlichen Aussagen treffen.

Der steile Anstieg der Systemlast-Kurve bei Log-Eintrag 260 ist dadurch zu erklären, dass vorher einige Splittings durchgeführt wurden (zu sehen in Abbildung 7.3). Die Verschiebung der Systemlastkurve in X-Richtung rührt daher, dass /proc/loadavg grundsätzlich verzögerte Werte liefert.

7.3.1.2 Freie und benutzte RegionController

Abbildung 7.3 stellt die verfügbaren sowie die bereits verwendeten RegionController der Anzahl an verbundenen Clients gegenüber. Somit sieht man hier, wie sich das Verbinden neuer Clients auf das Splitting der Regionen auswirkt.
Figure 7.3: Testreihe 1: Freie und benutzte RegionController sowie verbundene Clients
Image region_clients

7.3.2 Zweite Testreihe

Die Größe der Spielewelt wurde nicht geändert. Jedoch wurde die Spielewelt mit 3000 statischen und 2000 bewegenden Objekten gefüllt. Das Client-Limit pro Region wurde auf 8 Spieler pro Region gesenkt, so dass mehr Splitt-Vorgänge stattfinden sollten. Das sollte insgesamt die Last des Servers erhöhen, da sich letztendlich mehr Regionen ergeben und somit auch mehr Regions-Wechsel der Avatare stattfinden.

BotPlayer wurde angewiesen, 15 Clients und 10 RegionController pro Pool-Rechner zu starten. Dies kann man in den folgenden Kurven nachvollziehen. Die Clients sollten nun jedoch in einem Intervall von 10 Sekunden hintereinander gestartet werden.

Figure 7.4: Testreihe 2: Anzahl verbundener Clients, Anzahl totaler Verbindungen zum Server sowie LoadAvg (um den Faktor 5 gestreckt)
Image clients_cpu_2
Figure 7.5: Testreihe 2: Freie und benutzte RegionController sowie verbundene Clients
Image region_clients_2
Wie in den Abbildungen 7.4 und 7.5 dargestellt, ergeben sich etwas andere Ergebnisse. Wie man sieht, ist das Verhältnis von Gesamt-Verbindungen zu Client-Logins gestiegen, was aus der erhöhten Aktivität der RegionController resultiert. Da jedoch nicht mehr über 200 Clients verbunden sind, bleibt die Systemlast auf einem niedrigen Level.

http://www.psitronic.de/ti/mmpg/mmpg-peer_to_peer/
Menü

Home
Funstuff
Linux
Hardware
Distributionen
Spiele
Kontakt
Projekte
Java
Webcut
Strength and Honor
A-Mobile
Holy-Wars 2
Holy-Wars 3
-> Dokumentation
Biometrie
Performanzermittlung
-> Mmpg
-> Mmpg-peer to peer
Javadoc
Mmpgp2p-Server
Semantic Web
WSA



- Impressum -
designed using WebCut - Copyright (c) 2001-2008 by Markus Sinner