Schlagwort-Archive: performance

Dev-Blog Donnerstag 1/16

Dev-Blog Donnerstag 1/16

Von Entwicklern für Entwickler

[Horst (Slayer)]

Eine herausfordernde Woche liegt hinter uns. Mehr Spieler bedeutet zum einen, mehr Zeit für die Betreuung der Community aufwenden zu müssen (oder zu dürfen, denn mir macht das auch sehr viel Spaß) und zum anderen, dass Bugs durch mehr aktive Spieler nun viel schneller an Tageslicht kommen.

Unser Logging hat sich in dem Zusammenhang auch als etwas zu „chatty“ herausgestellt, so manchen Log-Level habe ich deshalb angepasst, damit wirklich wichtige Log-Einträge nicht drohen in der Menge unterzugehen.

Auch das Thema Performance poppt nun wieder auf. Insbesondere im Zusammenhang mit der Datenbank, kann das durch viele gleichzeitige Aktionen zu unangenehmen Situationen führen. Da gilt es nun, ein sehr wachsames Auge drauf zu haben. Bevor wir nun aber etwas refactoren, haben wir uns vorgenommen, für die betroffenen Klassen zuerst UnitTests zu schreiben. So ist auch diese Woche wieder der ein oder andere Test entstanden. Wie wir in Zukunft in dem Zusammenhang einen wichtigen Schritt vorwärts machen, beschreibt Iwan weiter unten.

Der Ingame Chat tut im Zusammenhang mit den neuen Spielern sehr gute Dienste, da er gut angenommen wird, um dort Tipps von „alten Hasen“, also Spielern, die schon länger spielen, zu bekommen. Und wir haben so die Möglichkeit, aktiv nach Problemen zu fragen und sofort einzugreifen, wenn es wo hakt. Auch der Blick „über die Schulter“ unserer Spieler bringt uns wichtige Erkenntnisse im Rahmen von potentiellen Einstiegshürden.

[Iwan (shlainn)]

Vor einer Weile haben wir einen Server für interne Aufgaben angeschafft. Bislang langweilt sich dieser etwas – er ist nur für das tägliche Backup der Datenbanken unserer verschiedenen Spiele verantwortlich. Zeit dies zu ändern.

Horst berichtet ja seit einer Weile über unser Dauerprojekt, möglichst viel vom eXperinox-Code durch automatisierte Tests abgedeckt zu haben. Das hilft, bei Veränderungen Fehler zu vermeiden – manchmal ist es bei historisch gewachsenem Code schwierig alle Stellen, an denen eine Änderung Einfluss hat, zu erkennen. Aber Unit Tests haben den „Nachteil“ dass man sie auch ausführen muss, sonst bringen sie nichts – und jeder weiß: Entwickler sind faul. Daher habe ich mich diese Woche mit verschiedenen Continuous Integration Tools beschäftigt.

Der Elefant im Raum ist Jenkins – ein Java-basiertes Tool, das ALLES kann. Und für das was es nicht kann, gibt es Plugins. Es ist auch notorisch kompliziert aufzusetzen, weshalb ich mich zunächst auf die Suche nach Alternativen begeben habe.

Eine solche Alternative ist PHPCI. Dieses Tool ist rein in PHP geschrieben, benötigt also keine zusätzliche Software auf dem Server, und bringt häufig genutzte Tools in der PHP-Entwicklung wie PHPUnit, PHP Mess Detector, PHP Code Sniffer und einige weitere im Installationspaket mit. Verwaltet wird das ganze, wie auch Jenkins, über den Browser.  Die Installation ist sehr einfach und relativ gut dokumentiert – nach einer halben Stunde hatte ich das Paket installiert, konfiguriert, eXperinox als Projekt hinzugefügt, und einen ersten Build mit Tests laufen lassen. Leider ist die Ausgabe etwas enttäuschend – ich konnte nicht einsehen, welche Tests erfolgreich gelaufen sind, oder wie viel von unserem Code bereits durch Tests abgedeckt ist. Diese Informationen sind sehr wichtig, um zu verstehen, wo wir am dringendsten nachbessern müssen.

Also zurück zu Jenkins. Ich muss vorab ein Geständnis machen: Ich bin Jenkins gegenüber etwas voreingenommen, da meine bisherigen Erfahrungen mit Java, egal ob auf dem Server oder als Client-Software, durchgehend unerfreulich waren – abgesehen von den Sicherheitslücken, die in regelmäßigen Abständen bekannt werden. Erfreut konnte ich jedoch feststellen, dass es einen Docker Container für Jenkins gibt, in dem alles feinsäuberlich verpackt ist – keine Installation, keine Java-Kontamination im System! Erste lokale Tests verliefen auch vielversprechend – doch dann stellte sich heraus dass Docker auf unserem Server nicht funktioniert (GRR Server4you vServer!). Also doch auf die klassische Art. Dankbarer Weise hat Marc Harter von StrongLoop (node.js) ein zweiteiliges Tutorial zur Einrichtung von Jenkins  verfasst, das den Prozess enorm erleichtert hat. Der langen Geschichte kurzes Ende ist, dass jetzt jedes Mal, wenn wir Codeänderungen in unser Git-Repository schieben, ein vollständiger Durchlauf der Unit Tests durchgeführt wird – und wir bei Fehlern in den Tests benachrichtigt werden.

screenshot113

Willkommen in der Zukunft, eXperinox!

Natürlich könnte Jenkins noch viel mehr, aber wir wollen uns langsam an die Materie herantasten und das System an unsere Bedürfnisse anpassen.

 

Dev-Blog Donnerstag 33/15

Dev-Blog Donnerstag 33/15

Von Entwicklern für Entwickler

[Horst (Slayer)]
Nach wie vor steht der Geburtstags-Event im Mittelpunkt meiner Tätigkeiten. Während die Spieler fleißig ihre Ressourcen ins nächste Solarsystem kippen, heißt es für uns, bereits damit zu beginnen, an den versprochenen Belohnungen zu arbeiten. Und ein Raumschiff mit Sonderlackierung hat mich wieder einmal Blender aufrufen lassen. Echt übel, wie schwer ich mich da immer tue, wenn ich das Teil länger nicht mehr bedient habe.

Der Party-Raumer, ein Frachter mit Sonderlackierung
Der Party-Raumer, ein Frachter mit Sonderlackierung

Auch die Community Betreuung kostet aktuell etwas mehr Zeit als üblich, denn natürlich liegt uns etwas daran, dass möglichst viele auf das 3-jährige Bestehen von eXperinox aufmerksam gemacht werden.

Dazu poste ich auch im ein oder anderen Browserspiel-Forum einen entsprechenden Beitrag, wie z.B. bei Webgamers oder Pewn.

Wincachegrind (zur Performance-Auswertung von Profiles) zickt herum. „cannot find call target“. Kurz gegoogeld und auf einen Windows Port des Originals KCachegrind gestoßen. Funzt einwandfrei und kann mehr. So mag ich das!

Last but not least: diese Woche geht’s für mich auf das SummerBreeze – mit dem guten Gefühl, jemanden wie Iwan Zuhause zu wissen, der sich um eXperinox kümmert.

[Iwan (shlainn)]

Letzte Woche fiel ich mehr oder weniger aus dem Flugzeug vor den Rechner um die Stretch-Goals für die Geburtstags-Spendenaktion einzubauen – so schnell hatten die eXperinox-Spieler die drei ursprünglichen Ziele geknackt. Danach ging es etwas gemütlicher zu und es dauerte fast eine Woche bis das vierte Spendenziel erreicht war – aber das aktuelle Ziel (Nr. 5) ist nach kaum 2 Tagen auch schon zu über 50% erfüllt – haben wir einen Nerv getroffen?

In unserem anfänglichen Übermut haben wir dem noXiversum erhöhte Produktion der gespendeten Ressourcen versprochen – ohne dass bisher ein Mechanismus im Spiel existiert hätte um das umzusetzen. Meine Aufgabe war es daher, ein solches System zu designen und zu implementieren. Dabei wollte ich die Gelegenheit nutzen und für zukünftige Ideen vorbauen, sodass wir flexibel und effizient alle denkbaren Arten von Boni mit diesem System abbilden können. Derzeit laufen letzte Tests, aber ich bin mit dem Ergebnis durchaus zufrieden.

Bevor das Geburtstags-Event am kommenden Samstag zum Abschluss kommt sind noch einige Dinge zu erledigen und vorzubereiten – ich hoffe unseren Spielern macht das Event genauso viel Spaß wie uns, und man darf gespannt sein, wie weit es mit den Spenden noch geht…