preDispatcher - speed up my slow Concrete5 website

Dienstag, 20. August, 2019

Meine Concrete5 Webseite wurde langsamer und langsamer. Sie wird auf einem Shared Hosting betrieben (was ohnehin nicht die schnellste Option sein kann) - hier kann ich zudem keinen Varnish oder anderen Caching Dienst installieren und davorschalten, sondern muss mich mit .htaccess und Standard-PHP-Mitteln behelfen können.

Das Initialisieren eines Requests in Concrete5 (Bootstrapping) braucht scheinbar sehr lange. Selbst statische Inhalts-Seiten, die ein aktives Fullpage Cache haben, benötigen für die Verarbeitung am Server mehr als 200 ms. Hinzu kommen für einen kompletten Request dann noch Netzwerkzeiten für Namensauflösung (DNS), Anfrage zum Server senden … und das Ergebnis zum Browser zurücksenden, was der Browser dann rendert. Meine schnellsten Seiten aus dem CMS waren bei 300 ms. Andere brauchten 3 Sekunden und mehr. Concrete5 ist einfach langsam.

Ich habe einen Cache geschrieben, der Concrete5 vorgeschaltet ist und im Filesystem seine Caching-Daten ablegt. Kurz er hat minimalste Anforderungen und arbeitet mit einem Shared Hoster. Dieses “Vorschalten” umgeht die lange Initialisierungszeit von Concrete5 - dies macht die Seite schnell.

Vor einigen Tagen habe ich eine erste Version meines preDispatchers eingespielt. Erwartungsgemäss muss man ein paar Kinderkrankheiten ausmerzen. Aber erste Ergebnisse in der Webseiten-Statistik (Matomo) zeigen, dass es eine gute Entscheidung war: die mittleren Seiten-Generierungs-Zeiten sanken von über 2s auf unter 0.4s

2019-08-20-predispatcher-generation-time-in-matomo.png

Der PreDispatcher besitzt eine Debugging-Ausgabe, die die Arbeitsweise veranschaulicht und den Unterschied deutlich macht. Das ist ein ungecachter Aufruf einer Seite mit Fullpage Cache in C5 - also inkl. Bootstrapping + Auslieferung einer in C5 gecachten Seite:

2019-08-20-predispatcher-uncached-concrete5-request-of-fullpage-cached-page.png

Der PreDispatcher speichert den Request, der nicht im Cache ist (oder dessen Caching Zeit abgelaufen ist). Der nächste Request auf dieselbe Seite wird dann schnell. Richtig schnell:

2019-08-20-predispatcher-cached-request.png

Wie lange eine Seite aus einem Cache kommt? Man definiert einen Default für alle Seiten. Mit einer Liste von Regex für aufzurufende URLS kann man die Standard-Vorgabe übersteuern und einen neuen Wert zuweisen.

Zudem gibt es eine Erkennung, was nicht gecacht werden darf - oder wo ein Cache verworfen werden muss. Ich kann mich im C5 Backend einloggen - und der Cache jeder mit Login aufgerufenen Seite wird verworfen.

Ich bin wohl auf dem richtigen Weg. Aber ein wenig Feintuning braucht es noch. Bei Interesse, schaut auf Github … oder fragt mich an :-)

Der PreDispatcher ist Freie Software - unter GNU GPL 3!

weiterführende Links:

  1. Github: pre-dispatcher
  2. Concrete5 webseite

jsclasses.org - Top user rated classes

Donnerstag, 16. Mai, 2019

Oh, was für eine kleine nette Überraschung: Das da bin ja ich :-)

2019-05-16-jsclasses-top-rated-classes.png

Mit dieser Klasse wird bei einem Passwort-Feld ein Div eingeblendet. Darin wird die Erfüllung der vorgegebenen Bedingungen (z.B. Anzahl Zeichen, Gross-/ Kleinschreibung, Anzahl Sonderzeichen) dargestellt - on the fly während der Passworteingabe.

Diese Klasse ist Freie Software und Open Source.

weiterführende Links:

  1. Axels Webseite: ahPwcheck
  2. Docs: Password checker (en)
  3. jsclasses.org: AH JavaScript Password Strength Check: Calculate and display the strength of a password (en)

PHP: komisch grosse Zeiten in Curl

Mittwoch, 8. Mai, 2019

Ich hatte wirklich seltsame Antwortzeiten mit der Curl-Bibliothek in PHP in meiner eigenen Monitoring-Anwendung.
Bei Verwendung von curl_getinfo($curl) ist der Wert von “total_time” ein Wert in Sekunden. Eigentlich. Bei einer Reaktionszeit von 16ms sollte es 0,016 sein, ich erhielt aber 16000.

Das Problem ist, dass sich die Werte der Curl-Funktion bei Verwendung von PHP mit mod_php korrekt verhalten - nur im FCGI Modus gibt es Zahlenwerte, die Faktor 1 Mio. zu gross sind.

Bei einer Antwort-Zeit von 16 ms sollte der Wert im Feld total_time 0.016 sein - unter FCGI kommt aber 16000 zurück.

2019-05-08-curl-time-values.png

Nach einer kurzen Suche, fand ich einen bestehenden Bugreport, wo ich meine Daten ergänzte. Mal schauen, ob da wohl was geht …

weiterführende Links:

  1. bugs.php.net- 76438: wrong curl_getinfo time values
  2. php.net: Funktion curl_getinfo()
  3. Github: IML AppMonitor

Virtualbox: Protocol error beim Mounten der Shared Folders

Mittwoch, 17. April, 2019

In meiner Virtualbox 6.0(.x) Instanz habe ich ein lokales Webentwicklungsverzeichnis mit mehreren Domains von Entwicklungsumgebungen als Shared Folder in eine CentOS VM geteilt. In jener sind die Verzeichnisse als Apache Webroots via /var/www/[Domainname]/public_html/ angesprochen.

Und wie das so bei Computern ist: von einem Tag auf den anderen funktioniert irgendwas nicht mehr. Heute: das Mounten der Verzeichnisse.

Versuch 1:

Ein Reboot der VM … brachte nichts.

Versuch 2:

Shared Folders funktionieren nur, wenn die Gästetools installiert sind. Es hätte ja durch ein OS-Update der VM einen neuen Kernel gegeben haben. Diese habe ich nochmals installiert. Es wurde ein neuer Kernel compiliert… was einen weiteren Reboot brauchte … es geht aber nicht.

Versuch 3:

So kommt man dem Problem dann näher:
Man öffnet die Logs - das geht via dem Icon rechts einer VM (oh, ich hatte beim Umstellung von Virtualbox 5 auf V 6 lange die Sicherungspunkte gesucht :-)) - hier Logs auswählen. Dann erscheinen mehrere Tabs - das erste davon brauchen wir - die VBox.log.

2019-04-17-virtualbox-01-show-logs.png

Darin taucht ein Fehler auf:

00:36:51.618960 ASSERT_GUEST_LOGREL F:\tinderbox\win-rel\src\VBox\HostServices\SharedFolders\mappings.cpp(762) 
... int __cdecl vbsfMapFolder(struct _SHFLCLIENTDATA *,struct _SHFLSTRING *,unsigned short,bool,unsigned int *): 
... pFolderMapping->cMappings == 0 || pFolderMapping->fGuestCaseSensitive == fCaseSensitive
00:36:51.618981 Incompatible case sensitivity setting: C:\data\htdocs: 2 mappings, insenitive, requested senitive!
00:36:51.619183 VMMDev: Guest Log: 06:57:31.461002 automount Error: vbsvcAutomounterMountIt: Failed to mount 
... 'htdocs' on '/media/sf_htdocs': Protocol error (-1,71)

Nach jenem

automount Error: vbsvcAutomounterMountIt: Failed to mount ‘htdocs’ on ‘/media/sf_htdocs’: Protocol error (-1,71)

kann man im Internet micht der Suchmaschine seiner Wahl suchen. Leider wurde ich trotz des Fehlercodes und Wortlaut der Meldung nicht fündig. Das fand ich unlustig. Ich bin also der erste Mensch auf der Welt, der dieses Problem hat :-)

Schauen wir bei den gemeinsamen Ordnern - das hatte ich eingestellt:

2019-04-17-virtualbox-02-shared-folder.png

Was aber klappte:

Ich habe die Shared Folder Defintion gelöscht … rechts das Order Symbol mit dem X … im Log erschien

00:39:53.656135 SharedFolders host service: Removing host mapping 'htdocs'
00:39:53.743943 GUI: UIMediumEnumerator: Medium-enumeration finished!

Dann wurde das zuvor Gelöschte 1:1 wieder eingerichtet.

00:40:26.398568 SharedFolders host service: Adding host mapping
00:40:26.398589     Host path 'C:\data\htdocs', map name 'htdocs', writable, automount=true, automntpnt=, create_symlinks=false, missing=false
00:40:26.452420 GUI: UIMediumEnumerator: Medium-enumeration finished!
00:40:27.403966 VMMDev: Guest Log: 07:01:07.246159 automount vbsvcAutomounterMountIt: Successfully mounted 'htdocs' on '/media/sf_htdocs'

Dies hat er eingerichtet - und sofort war es auch in der VM ohne weiteres Zutun gemountet.
Last but not least habe ich die VM nochmals rebootet, um zu schauen, ob es auch nach einem Neustart noch funktioniert … yep, auch dies ging.

Flatpress lebt weiter

Samstag, 23. Februar, 2019

Nachdem bei Flatpress über Jahre nicht mehr viel weiterging, habe ich Anpassungen (die in dessen Forum genannt wurden) für mich gemacht und gar angefangen ein anderes Blog Tool zu suchen. In meinem Blog sind Inhalte seit 2008. Die Inhalte zu übernehmen, ist so eine gewisse Hürde, die mich abschreckt.

Aber all das entfällt ja nun :-) Am 22. Februar gab es eine neue Version, die gar PHP 7.3 komptibel ist.

Ein Dankeschön an Arvid und seine Helfer!

Anbei die Beschreibung des Updates von 1.0x auf 1.1 mit Übernahme des Inhalts. Bei der Variante “Überschreiben der bestehenden Dateien” bleibt tendeziell Unnützes über.
Anm.: dies ist inoffiziell - es ist die Beschreibung des Vorgehens auf meiner Installation.

  1. Backup: das Verzeichnis des Blogs “/blog/” wurde umbenannt nach “/blog_OLD/”
  2. Unzip der version 1.1 nach “/blog/”
  3. Beiträge und Bilder: Kopieren des Verzeichnisses /blog/fp-content/
  4. Theme: Kopieren des Verzeichnisses /blog/fp-interface/themes/[theme]
  5. Plugins: gehe in das Backend des Blogs blog/admin.php?p=plugin … wenn ein fehlendes Plugin gemeldet wird: Kopieren des Verzeichhisses /blog/folder fp-plugins/[pluginname] (Kontrolle mit Reload im Browser)
  6. Die Toolbar des Editors habe ich mir erweitert - im BBCode plugin wurden einige weitere Buttons hinzugefügt /blog/fp-plugins/bbcode/tpls/toolbar.tpl
  7. Pretty-Urls waren aktiv? dann die /blog/.htaccess übertragen
  8. Flatpress-Index neu erstellen: Dazu anmelden, Wartung anklicken und den Link anklicken [Den Flatpress Index neu erstellen]
  9. Einmal den Browsercache löschen (Ctrl+Shift+Delete), damit Javascript- und CSS Elemente von der neuen Version geladen werden

UPDATE:
3.3.2019 - Dank an Matthias (Laborix): Neuerstellen des Index wurde hinzugefügt.

weiterführende Links:

  1. www.flatpress.org