DroidWiki:Tech-News

Aus Android Wiki
Die druckbare Version wird nicht mehr unterstützt und kann Darstellungsfehler aufweisen. Bitte aktualisiere deine Browser-Lesezeichen und verwende stattdessen die Standard-Druckfunktion des Browsers.
Aktuelle Version
der MediaWiki-Software:
1.41.0-wmf.5

Als Pendant zu den Projekt-Neuigkeiten, interessieren sich ggf. auch einige Leute für die Technik hinter DroidWiki.de und die entsprechenden Änderungen. auf dieser Seite sollen die wichtigsten Änderungen beschrieben und aufgezeigt werden.

16.12.2015 Neues Übersetzungstool für das Android Traning

Oberfläche der Translate-Erweiterung beim Übersetzen

Aktuell ist es so, dass für die Übersetzung des Android Trainings lediglich der normale Editor zur Verfügung steht. Das macht das Übersetzen nicht nur sehr anstrengend, es macht auch keinen wirklichen Spaß. Daher versuchen wir das Ganze jetzt mit einer neuen Lösung, und zwar der Translate Erweiterung, welche auch bei zahlreichen anderen MediaWiki-Seiten eingesetzt wird, die mehrsprachig aufgestellt sind, allen voran mediawiki.org und das TranslateWiki (welchem wir auch die Mehrsprachigkeit der MediaWiki-Software zu verdanken haben).

Nun ist diese Erweiterung auch auf droidwiki.de verfügbar, wird allerdings nur auf das Android Training eingesetzt und auch hier anfangs nur auf einigen Testseiten, um etwaige Kinderkrankheiten zu identifizieren und beheben zu können. Ein erstes Beispiel für die Verwendung der Erweiterung, wie das Ganze aussieht und wie sich das Handling so anfühlt, findet ihr auf der Seite Android Training: Eine einfache Benutzeroberfläche erstellen. Das Übersetzen ist einfach durch einen Klick auf den Link Diese Seite übersetzen erreichbar, oder, sofern eine übersetzte Seite geöffnet ist, ganz normal über den Bearbeiten Button. Der Editor teilt den Text in handliche Stücke und erlaubt eine Side-to-Side Bearbeitung.


27.11.2015 Software-Updates zum Jahresende

Jetzt geht sie langsam los: die Weihnachtszeit und der Endspurt zum Jahresende. Das bedeutet auch einige Einschränkungen bei den regelmäßigen Software-Updates der DroidWiki-Basissoftware MediaWiki. In der Regel wird jeweils wöchentlich die neueste Version der MediaWiki-Software, inkl. allen verfügbaren Updates für unsere verwendeten Erweiterungen, (meist am Freitag) auf die Server von DroidWiki.de verteilt. Dabei orientieren wir uns an den Zeitplan der Wikimedia-Foundation, die die sogenannten wmf-Versionen von MediaWiki für ihre eigenen Projekte verwendet und erstellt. Daraus ergeben sich neben Weihnachten auch einige andere Feiertage, die die Erstellung der wmf-Versionen verzögern. Aus diesem Grund, werden wir in diesen (unten genannten) Wochen ebenfalls kein reguläres Software-Update durchführen.

Selbstverständlich betrifft dies nicht kritische Fehlerbehebungen und Sicherheits-Patches. Zudem werden Software-Updates für andere Software-Pakete, falls nötig (also regulär), auf die Server verteilt.

In folgenden Wochen werden keine regulären Software-Aktualisierungen der MediaWiki-Software erfolgen:[1][2]

Kalenderwoche (KW)

(Datum vom Freitag der KW)

Aktualisierung auf MediaWiki Version Begründung
48

(27. Nov.)

- Thanksgiving (US-Feiertag)
49

(04. Dez.)

- First of Dec Fundraising[3]
50

(11. Dez.)

1.27.0-wmf.8 -
51

(18. Dez.)

1.27.0-wmf.9 -
52

(25. Dez.)

- Weihnachtsfeiertag

(& End of year Fundraising)

53

(01. Jan.)

- Neujahr

(& End of year Fundraising)

1

(08. Jan)

- Wikimedia Developer Summit 2016 und WMF All Hands
2

(15. Jan)

1.27.0-wmf.10 -
3

(22. Jan)

1.27.0-wmf.11 Rückkehr zu wöchentlichem Updatezyklus

Siehe auch

  1. Interner Lua-Fehler: Der Interpreter beendet sich mit dem Status 127.
  2. Vorlage:Internetquelle/Wartung/Zugriffsdatum nicht im ISO-FormatInterner Lua-Fehler: Der Interpreter beendet sich mit dem Status 127. In: Interner Lua-Fehler: Der Interpreter beendet sich mit dem Status 127. Abgerufen am 2015-11-27.
  3. Interner Lua-Fehler: Der Interpreter beendet sich mit dem Status 127.


21.11.2015 Jobrunner anstelle von Cronjob

Die sogenannte JobQueue von MediaWiki ist ein wichtiger Bestandteil von MediaWiki, um die Performance zu verbessern. Mit Hilfe der JobQueue können Performance-intensive Aufgaben, bzw. Aufgaben, die eine längere Zeit in Anspruch nehmen, asynchron (also unabhängig von Aufrufen des Frontends) ausgeführt werden. In der Standardkonfiguration wird ein Job pro Seitenaufruf ausgeführt. Bei DroidWiki wurde diese Einstellung auf 0 reduziert (sodass kein Job pro Seitenaufruf ausgeführt wird), um die Performance zu verbessern. Stattdessen wurden die Jobs automatisiert alle 5 Minuten durch ein Cronjob auf dem Server ausgeführt. Das Ausführen von Jobs unabhängig von Seitenaufrufen zu machen, macht durchaus Sinn und wird so auch bei anderen MediaWiki-Projekten durchgeführt (wie bspw. der Wikipedia). Ein Nachteil: Bei Aktionen auf der Webseite, die einen Job in die JobQueue einstellten, war ein Ergebnis bisher erst nach (im Worst Case) 5 Minuten sichtbar. Das wird bspw. beim Hochladen von Dateien ein Problem, da diese erst nach 5 Minuten im Suchindex erscheinen (welcher per Job aktualisiert wird) und somit erst dann im VisualEditor zur Verfügung stehen. Andere Negativeffekte können zudem zusätzlich auftreten.

Um diese negativen Auswirkungen bestmöglich zu eliminieren, musste eine bessere Lösung als ein Cronjob her. Die Lösung: der MediaWiki JobRunner service. Dieser kleine, PHP-basierte, Service, erlaubt es, Jobs innerhalb weniger Sekunden nach deren Einstellung auszuführen (bzw. je nach der aktuellen Menge der Jobs in der JobQueue nach einer gewissen, individuellen Wartezeit). Durch die kontinuierliche Ausführung von Jobs kann nun im Mittel eine schnellere Ausführung von Jobs gewährleistet werden. Die Abhängigkeit an ein bestimmtes Zeitraster entfällt ebenfalls, da die Ausführung nun nur noch von der Menge an Jobs in der Warteschlange abhängt, nicht mehr von einer bestimmten Zeit. Zusätzlich zu der Installation des Jobrunner service als Upstart service auf dem DroidWiki Server, musste die JobQueue auf Redis umkonfiguriert werden (der Jobrunner ist auf eine Redis-JobQueue angewiesen), was mit dem Change 1140 durchgeführt wurde.

Nach einer kurzen Testphase blieb als einzige Aufgabe lediglich, den Cronjob von seinen Diensten zu entbinden und bis auf Weiteres zu deaktivieren. Ab nun sollten alle Aufgaben, die auf einen Job angewiesen sind, schneller als vorher erledigt werden :)


30.05.2015 DroidWiki, HHVM und mehr

Wer neben der DroidWiki auch die Neuheiten in der Wikipedia, welche von der Wikimedia Foundation betrieben wird, verfolgt, wird bereits zum Ende des letzten Jahres mitbekommen haben, zumindest wenn auch die technische Seite interessiert, dass zur Auslieferung der Seiten nun HHVM, eine alternative PHP-Implementierung, genutzt wird.[1][2] Die Vorteile des Wechsels merken vor allem die Nutzer der Wikipedia durch eine schnellere Beantwortung ihrer Anfragen. Auch wenn die DroidWiki ein vergleichsweise sehr kleines Projekt ist, haben auch wir uns Gedanken gemacht, wie wir von dieser Entwicklung profitieren können. Das Ergebnis darf ich heute auf dieser Seite etwas präziser darlegen.

Der aktuelle Zustand

Die Messungen der Ladezeiten der Seiten der DroidWiki, sowohl Stichprobenartig und im Mittel, sind leider nicht sehr vielversprechend gewesen. Im Mittel mussten wir uns mit ca. 7 Sekunden zufrieden geben, bis eine Seite der Wiki vollständig geladen wurde (nach ca. 2-4 Sekunden wurde der Inhalt angezeigt). Damit sind wir weit entfernt von einer hochperformanten Seite, auf der das Surfen und Herumstöbern Spaß macht. Unsere Bemühungen, die Seitenladezeiten drastisch zu reduzieren haben in letzter Zeit immer mehr ihre Grenzen in der für die Wiki zur Verfügung stehenden Technik und Infrastruktur gefunden.

Die Power von HHVM (und einiges mehr)

Es mussten also neue Lösungen, Ideen und Ansätze her. Als sinnvollsten Schritt kann man selbstverständlich die Anknüpfung an die Erfahrungen und Erfolge der Projekte der Wikimedia sehen, immerhin bewältigen diese Lösungen eine der TOP-Webseiten der Welt. Der Plan, HHVM als neue PHP-Implementierung für die DroidWiki zu nutzen wurde schnell gefasst, woraufhin sich ein Problem stellte: Unser derzeitiger Hoster, der bisher sehr zufriedenstellend funktionierte, würde eine HHVM-Nutzung sicher nicht einfach so durchwinken, zudem ist der Wechsel des PHP-Interpreters auch nur ein Schritt, bei dem wir sicher nicht aufhören können und wollen. Also muss ein neuer Hoster her, der den neuen, gewachsenen Anforderungen der DroidWiki gerecht werden kann, der sich allerdings auch preislich in einem angemessenen Rahmen bewegt. Nach einer längeren Suche und vielen Vergleichen von Angeboten haben wir den für uns passenden gefunden: die netcup Gmbh aus Karlsruhe!

Nach der Bestellung unseres neuen Servers ging es an die Einrichtung einer ersten Testversion (einer Kopie der DroidWiki) und zur nächsten Frage: Bisher haben wir Apache als Webserver verwendet, der auf Anfragen an droidwiki.de geantwortet hat. Wollen wir auch beim neuen Server weiterhin auf Apache setzten oder eine Alternative nutzen? Nach einigen Tests und vielen Test- und Erfarhungsberichten (speziell auch bei der Verwendung mit einer eher kleinen MediaWiki-Installation und begrenzten technischen Ressourcen) kristallisierte sich nginx als Gewinner heraus, sodass wir uns beim neuen Server von Apache trennen und nginx als neues Mitglied unseres Stacks begrüßen können! :)

Da jetzt der Webserver fest steht und die Installation von nginx und HHVM (im fastcgi-Modus) relativ problemlos und zügig von statten ging, kommt erneut eine Frage auf, die es zu beantworten gilt: MySQL oder MariaDB? Auch hier gilt als großes Beispiel die Erfahrungen der Wikimedia Foundation aufzugreifen und zu prüfen, ob sich diese auf unser kleines Projekt übertragen ließen. Bereits im April 2013 wechselten die mitunter größten Projektseiten der WMF (Wikimedia Foundation) von MySQL zu MariaDB 5.5.[3] Neben dem Performance-Zuwachs (den wir mit dem Wechsel unserer Infrastruktur natürlich vorrangig verfolgen) schließen wir uns gerne den restlichen Argumenten der WMF an und können diese übernehmen, bspw. die Entwicklung ausschließlich als Open Source Projekt, was uns die Entscheidung hin zu MariaDB sehr vereinfacht hat, wenn man es so sagen möchte.

Neben dem Wechsel der eben genannten Techniken, haben wir auf dem neuen Server auch einiges an Caching zu bieten. Neben der Verwendung von Memcached als Objekt-Cache nutzen wir nun auch Varnish als letzten Cache-Layer, der allerdings aktuell nur den Resourceloader cached (ggf. werden zu einem späteren Zeitpunkt auch Seiten der Wiki gecached).

Unser kompletter Stack sieht wie folgt aus:

  • Ubuntu 14.04.2 LTS
  • nginx
  • Varnish 4.0.3
  • HHVM 3.7.0
  • MariaDB 5.5
  • MediaWiki 1.26wmf8
  • Elasticsearch 1.4.4

Konklusion

Eine wirklich aussagekräftige Bewertung des neuen Stacks und der neuen Server-Infrastruktur kann es selbstverständlich nicht direkt nach dem Wechsel geben, allerdings sind die ersten Test- und Messwerte vielversprechend: Bis zu 70% als Spitzenwert konnten wir die Ladezeit einzelner Seiten reduzieren, im Mittel kommen wir immer noch auf Messwerte von guten bis sehr guten 40-50%. Natürlich werden wir auch in Zukunft weiter darauf hinarbeiten, die DroidWiki noch besser und performanter machen, um euch den Besuch und das Herumstöbern so angenehm wie möglich zu machen!

  1. Interner Lua-Fehler: Der Interpreter beendet sich mit dem Status 127.
  2. Interner Lua-Fehler: Der Interpreter beendet sich mit dem Status 127.
  3. Interner Lua-Fehler: Der Interpreter beendet sich mit dem Status 127.