Moodle wieder stabil

[Daniel Baumann]

Hallo zusammen

seit unserem letzten Mail...

  https://lists.bfh.ch/pipermail/bfh-moodle-announce/2017-March/000058.html

..hatten wir noch zwei applikationsspezifische Dinge offen:

  * Webfonts mit Internet Explorer:
    - wegen starken Security Settings unserer Apache BFH-Defaults
      haben Webfonts mit Internet Explorer nicht funktioniert,
      d.h. die Fonts auf der Moodle Webseite sahen im IE nicht so
      "schoen" aus.
    - Behoben am 6.3.

  * Lockup der Applikation:
    - Seit der Migration auf Moodle 3.2 gibt es zwischen 2 und 3 Mal,
      zufaelligverteilt pro 24h, ein je 5 minuetiges Lockup von
      Moodle (d.h. die Webseite ist quasi offline weil die Applikation
      sich selbst sperrt).
    - Das Problem ist Load-unabhaengig, ein simpler Bug in Moodle
      selbst.
    - Behoben am 7.3. (technische Erlaeuterung siehe unten)

Auch fuer diese Applikationsprobleme gilt: waere getestet worden, waeren
diese beiden Applikationsfehler vor der Migration zum FS17 Start
entdeckt und behoben worden.

Deshalb moechten wir nocheinmal mit Nachdruck versichern, dass wir das
Upgrade auf Moodle 3.3 im Herbst 17 nur durchfuehren wenn:

  * Testverfahren/Checklisten fuer die Applikation ausreichend da sind

  * nur wenn alle Tests bis zum Stichtag erfolgreich sind,
    wird die Migration durchgefuehrt, sonst verschiebt sich die
    Migration automatisch auf die naechsten Semesterferien.

Wir sind sicher, dass wir damit die Applikationsseite stabilisiert und
professionalisiert haben.

---

Technische Erklaerung zum Lockup-Problem:

  * Wenn ein Browser eine Webseite laedt, muss er in der Regel nicht nur
    ein HTML File herunterladen, sondern auch mehrere Bilder,
    Javascript und CSS Files.

    Fuer die https://moodle.bfh.ch Startseite sind es z.B. aktuell
    33 einzelne Dateien.

  * Fuer jedes einzelne File musste der Browser, frueher, eine eigene
    Netzwerkverbindung (TCP) zum Server aufbauen. Bei vielen einzelnen
    Files bedeutet das einen hohen Overhead (TCP Handshake: Server und
    Client einigen sich darauf dass sie sich gegenseitig sehen und
    ab dann mit den richtigen Settings kommunizieren koennen).

    Konkret: Einmal Netzwerkverbindung aufbauen mit TCP-Handshake dauert
    rund 0.2 Sekunden. Bei 33 Datein bedeutet das dass das Aufbauen der
    Seite (wenn seriell heruntergeladen wuerde) mindestens
    33 * 0.2s = 6.6s dauert - egal wie schnell der Client oder der
    Server sind.

    Kann man etwa damit vergleichen, wie wenn man fuer jedes Reloaden
    einer Webseite sich mit einem Analog-Modem ins Internet neu
    einwaehlen muesste (beep-beep-beep-beep... die aelteren unter
    uns erinnern sich :).

  * Um dies zu verhindern, koennen Webserver und Browser einmal
    geoffnete Verbindungen fuer eine gewisse Zeit offen lassen (Keep
    Alive). Dabei werden alle folgenden Files ueber diese einzige,
    bereits bestehende Verbindung heruntergeladen, es entfaellt der
    Overhead von zusaetzlichen TCP Verbindungsauf- und abbau, und die
    Files koennen schneller herunter geladen werden.

  * Dies ist eine Praxis die mit quasi allen Webservern und Browsern
    auf praktisch allen Betriebssystemen seit Anfang 2000 standard ist.

    Das gleiche Verfahren wird fuer viele Dienste welche TCP
    Verbindungen machen verwendet (OpenSSH, alle was Datenbank-Systeme
    sind, Proxies, Loadbalancer, etc.) und ist absolut standard.

  * Fuer Webserver gilt noch speziell, dass TCP Keep Alive schon immer
    standardmaessig eingeschaltet ist/war, weil eine Webapplikation
    *eigentlich* nichts falsch machen kann - welche Files wie
    ausgeliefert werden hat die Webapp nicht zu interessieren.

    Darum umso erstaunlicher dass Moodle ab Version 3.2 mit TCP Keep
    Alive nicht mehr sinnvoll funktioniert (ja, wir haben ueberprueft
    dass es sich nicht um Connection Limits oder RAM Limits handelt -
    es ist ein Moodle Problem das in der Moodle Dokumentation
    ansatzweise erwaehnt wird).

  * Seit ich am Dienstag Abend um 19:50 Keep Alive abgeschaltet haben,
    laeuft Moodle wieder stabil ohne einen einzigen Aussetzer.

    (Wir hatten noch zwei kurze Aussetzer von AAI am Dienstag und
    Mittwoch, diese haben aber nichts mit dem Moodle System zu tun)

  * Nota Bene: Bei SQL Datenbanken macht man sich gleiche Verfahren zu
    nutze, Stichwort Persistent Connection.

    Dabei wird nicht fuer jedes Query eine neue Verbindung zur
    Datenbank auf- und wieder abgebaut, sondern es wir eine permante,
    bleibende Verbindung zur Datenbank etabliert, worueber dann alle
    Queries nacheinander durchlaufen. Dadurch werden DB Zugriffe
    enorm schneller.

    Persistent Connections zu DBs gilt im Webapp Umfeld schon seit
    ebenfalls ca. 15 Jahren als Standart. Wie auch bei TCP Keep Alive
    kann es der Webapp eigentlich egal sein, wie "schnell" die Queries
    zurueckkommen - ebenfalls erstaunlich ist dass Moodle noch nie mit
    mit Persistent DB Connections funktioniert hat (was u.a. auch ein
    Problem im Herbst 2016 war - mit Persistent Connections haetten wir
    deutlich weniger DB Performance Probleme gehabt weil massiv weniger
    Verbindungs-Overhead).

  * Kleines Goodie zum Schluss fuer alle die es bis hierher geschafft
    haben: man koennte ja jetzt denken, dass die Moodle Seite ohne
    Keep Alive jetzt sehr langsam ist.

    Ja, sie ist geringfuegig langsamer (ca. 5%), aber nicht ein
    mehrfaches langsamer wie im Beispiel oben mit den 6s Ladezeit bei
    33 Files.

    Grund: moderne Browser der letzten knapp 10 Jahre laden Dateien,
    unabhaengig von Keep Alive, nicht seriell herunter sondern
    parallel (Stichwort HTTP Pipelining). Dabei werden mehrere
    Verbidnungen gleichzeitig aufgemacht, welche dann jeweils via Keep
    Alive noch offen gehalten werden. Standartmaessig sind dies je nach
    Browser zwischen 4 bis 8 Verbindungen gleichzeitig.

    D.h. bei unserem Rechenbeispiel von oben mit 33 * 0.2s = 6.6s
    muss nochmals durch z.B. 4 geteilt werden, wir haben dann
    trotz Abschalten von Keep Alive eine (Mindest)Ladezeit von 1.7s
    (Rendering etc. nicht mit Einberechnet).

    Moodle ist also nicht mehr ganz so schnell, aber voellig ausreichend
    schnell und immer noch das schnellste Moodle das wir an der BFH je
    hatten.

Gruesse,
Daniel

-- 
Berner Fachhochschule / Bern University of Applied Sciences
IT-Services / Team Infrastructure Services
Daniel Baumann
IT System Engineer Linux
___________________________________________________________
Dammweg 3, CH-3013 Bern
Phone direct +41 31 848 48 22
Phone Servicedesk +41 31 848 48 48
daniel.baumann at bfh.ch
https://servicedesk.bfh.ch
https://www.bfh.ch
https://linux.bfh.ch