Author Archives: Ralph Mönchmeyer

DSGVO – wir stoppen Google-Analytics nach einem Test des Verhaltens unserer Leser zu Cookie- und GA-Hinweisen …

Posted on by

Liebe Leser des Blogs,
wie viele andere schlagen wir uns gerade mit dem Thema DSGVO (bzw. EU GDPR) herum. Ein Thema ist dabei Google Analytics, kurz [GA]. Auch wir haben bislang in diesem Blog ein Plugin verwendet, um mittels GA feststellen zu können, wie oft unser Blog besucht wird und welche Artikel unsere Besucher am meisten interessieren. Wir haben dies bislang für legitim und auch sinnvoll gehalten. Nun hat sich unsere Meinung aber geändert.

Wie reagiert der Besucher von Websites auf Cookies und Google Analytics, wenn er die Wahl hat?

Das Gute an der DSGVO (EU GDPR) ist, dass man sich auch als Webseiten-Betreiber ein paar unangenehmen Fragen stellen muss. Eine Frage, die ich selber immer wieder verdrängt habe, ist:

Wie reagiert eigentlich der/die Besucher/in einer Web-Site, wenn er/sie entscheiden kann, ob Cookies verwendet werden und ob sein Verhalten mittels GA auf der Site getrackt wird oder nicht?

Wir machen uns dabei folgenden Aspekt zu wenig klar: Web-Site-Betreiber leisten ja eigentlich dem geschäftsbedingten Daten-Sammeltrieb von Google Vorschub, indem sie/wir vermeintlich zum eigenen Vorteil einen attraktiven und gut funktionierenden Service von Google nutzen. Gerade in im Falle von Google Analytics geht es aber nicht nur um unsere eigenen Daten. Die nachfolgende Frage drängt sich auf:

Kann man testen, wie der User oder Leser auf Google Analytics reagiert, wenn er rechtzeitig informiert wird – und eine Option hat? Antwort: Ja, das kann man – und sollte es im Vorfeld der DSGVO auch tun. Wir haben eine Woche lang – eher unfreiwillig – einen solchen Test gemacht. Hier ist unsere Geschichte, die uns selbst gestern ein wenig ungläubig auf GA-Daten zum Blog blicken ließ …

Erfahrung mit unseren Lesern, einem Cookie/Google-Analytics-Banner und GA-Opt-Out im Verlauf einer Woche

Am 01. Mai habe ich mich aufgrund der DSGVO mit verschiedenen Plugins und Cookie-Bannern auseinandergesetzt. Zudem mit Plugins, die ein Google-Analytics-Opt-Out durch den Leser ermöglichen. In den Blog integriert wurde dann einerseits ein Cookie-Banner-Plugins der italienischen Regierung, das wir als gut erachtet hatten (s.u.). Auf diesem Banner wiesen wir auf Google Analytics hin. Zusätzlich kam auch ein Opt-Out-Plugin bzgl. Google Analytics zum Zuge.

Eine Woche später mussten wir folgenden, für uns doch ziemlich überraschenden Effekt konstatieren:

Laut Auswertung der “Google Analytics”-Statistik ging die Anzahl der Besucher dieses Blogs am 02.05. angeblich von durchschnittlich 150 Besuchern pro Tag schlagartig auf 3 oder 4 pro Tag herunter. Tendenz im Laufe der Woche fallend. Gestern war es nur noch 1 Besucher am ganzen Tag.

Irgendwie nicht lustig … Ein wenig Studium des Programmablaufs machte aber deutlich, dass das ein Scheineffekt war/ist – allerdings ein interessanter. Denn ein Gegentest zeigte, dass die veränderte Google-Analytics-Statistik etwas über die Haltung und Meinung unserer Besucher aussagt.

Die Auswirkung restriktiver und besucher-freundlicher Cookie-Banner

Wir gehen nach einer zwischenzeitlichen Analyse davon aus, dass der beobachtete GA-Effekt auf eine gewollte Wechselwirkung des Cookie-Banner-Plugins mit dem üblich “Google Analytics”-Skript in den Webseiten zurückzuführen ist. Das sog. “EU-Cookie-Law”-Plugin bietet nämlich als eines von wenigen eine Option an, die ich für absolut fair und richtig halte und deshalb aktiviert hatte:

Das Cookie-Banner-Plugin unterbindet in Webseiten integrierte Skripte, die ja potentiell weitere Cookies setzen und lesen könnten, so lange, bis eine explizite User-Zustimmung zur Cookie-Nutzung erfolgt ist.

Das verhindert technisch nun auch
nicht jede Art von Benutzer-Analyse: Bereits der PHP-Code der Seite könnte ja Session-Cookies und auch (verschlüsselte) Cookies mit weiteren tiefergehenden Informationen zum Besucher aufgrund von Browser-Informationen setzen und zumindest im Zuge von Seitenwechseln bestimmte Dinge auswerten. Viele WordPress-Plugins und Themes etwa setzen eigene (relativ harmlose) Cookies zur dynamischen Ablaufsteuerung, z.B. im Zusammenhang mit Bildgalerien. Detailliertere Auswertungen des Nutzerverhaltens setzen aber Javascript oder andere Skripts am Client (Browser/App) und bestimmte Cookie-Typen mit unterschiedlichen Informationen voraus.

Deshalb bietet das Plugin der italienischen Regierung die Option, cookie-fähige Skripte zu unterbinden, die auf der Client-Seite – also im Browser – ausgeführt werden. Das betrifft u.a. JS, Flash. Und natürlich Google Analytics; kaum überraschend setzt das GA-Skript ja gleich mehrere (3) Cookies.

Fairness gegenüber dem Besucher von Webseiten

Aus unserer Sicht spiegelt die Option des italienischen Cookie-Banners den Geist der DSGVO wieder… Der User soll nicht nur informiert werden, sondern auch ein wenig Einfluss auf das Geschehen haben, wenn seine Daten betroffen sind.

Stimmt der Besucher des Blogs durch Klicken auf den angebotenen Button zu, so ist das alles kein Problem. Das Script für Google Analytics läuft dann regulär ab; das Verhalten des Users auf der besuchten Seite wird direkt registriert und kann vom Inhaber der Seite auch live mitverfolgt werden. Was aber, wenn der Besucher den Button bzw. das gesamt Cookie-Banner aus guten Gründen ignoriert? Eine Folge ist, dass das Mini-Skript von Google Analytics dann nie zum Zuge kommt ….

Der vorsichtige User ignoriert Cookie-Banner systematisch …

Nun ist das bewusste Ignorieren des Cookie-Banners eine völlig verständliche Reaktion. Ich selbst wähle dieses Handlungsmuster laufend – u.a. und im Besonderen auch auf Seiten von Suchmaschinen-Herstellern. Ein Motiv ist dabei:
Warum sollte ich etwas zustimmen, das nicht explizit einer Wahl sondern eher einer reinen Kenntnisnahme entspricht? Und warum sollte ich etwas zustimmen, bei dem ich die Folgen nicht abschätzen kann?

Implizit müsste ein derart vorsichtiger Benutzer dabei davon ausgehen können, dass dann eben auch nichts außer einfachen Session-Cookies zum Tragen kommt. In Wirklichkeit ist dies leider nur bei einem kleinen Teil von Web-Sites der Fall. Das Cookie-Informations-Banner wird meist nur aus Alibi-Gründen angezeigt; das Nicht-Anklicken des OK-Buttons hat vielfach keine Wirkung im Sinne einer Cookie-Blockade. Im Fall unseres Cookie-Banners war das jedoch anders.

Gegentests

Ich habe am gestrigen und heutigen Nachmittag dann mal getestet, was passiert, wenn ich die Sperre von Scripts über das Cookie-Banner wieder deaktiviere. Na, ihr erratet es schon:

An beiden Tagen wurden sofort wieder etwa 15 Besucher des Blogs innerhalb von jeweils ca. 30 Minuten Testzeitraum registriert. Das konnte ich live in unserem GA-Account verfolgen. Am Nachmittag ist das auf unserem Blog Durchschnitt. Damit ist die Theorie wohl richtig, dass unsere (intelligenten!) Besucher das Cookie-Banner entweder schlicht ignorieren oder systematisch eine ebenfalls angebotene Opt-Out-Alternative gewählt haben.

Konsequenz 1

Eigentlich sind Banner,

  • die ein Zustimmung zu Cookies anfordern und
  • die zulassen, dass clientseitig ablaufende Skripts im Hintergrund mehr als einfache Session-Cookies zur Steuerung des Seitenablaufs setzen, wenn der User das Banner ignoriert,

eine Farce. Wie gesagt: Ich selbst erwarte wider besseren Wissens, dass keine Zustimmung durch Button-Klick bedeutet, dass auch nichts passiert.

Aus meiner Sicht dienen die von GA dynamisch gesetzten Cookies jenseits meiner persönlichen
statistischen Interessen aber auch weiterreichenden Anliegen von Google (s.u.)! Es wäre also gegenüber unseren Lesern nicht fair, das GA-Skript nicht zu unterbinden, wenn der User das Cookie-Banner und seinen Button absichtlich ignoriert.

Konsequenz 2

Ignorieren die meisten unserer Besucher aber das Cookie-Banner tatsächlich absichtlich, so wird bei fairer Einstellung des Cookie-Banners Google Analytics für uns, vermutlich aber auch für andere völlig nutzlos. Das hat uns die Erfahrung der letzten Woche eindeutig gezeigt.

Die “neuen” Google-Bedingungen für die Nutzung von Google Analytics

Hinzu kam, dass man aufgrund der DSGVO als Nutzer von Google Analytics nun ja auch den neuen Google-Bedingungen für die Nutzung von Analytics zustimmen muss. Hmmmm – ausgedruckt sind das 13 Seiten, die Google da unverschämterweise nur in Form eines kleinen Popups anbietet, bei dem man sich dann den Mittelfinger wund-scrollt. Allein das sollte einen schon misstrauisch machen…. Zudem erhielt ich die neuen Nutzungsbedingungen in unserem Google-Account nur auf Englisch angeboten – obwohl Google natürlich sehr wohl erkannte, dass ich mich aus Deutschland auf der GA-Verwaltungsseite angemeldet hatte.

Ich muss nach einer längeren Lektüre leider sagen,

  • dass ich die neuen (englisch verfassten) Bedingungen mindestens genauso skeptisch sehe wie die von mir in diesem Blog zuletzt so kritisierten Nutzungsbedingungen von Facebook
  • und dass ich die Google-Bedingungen z.T. – wegen der ausgesprochen verklausulierten Anwaltssprache – als noch unverständlicher einstufe.

Es wird Leser meines früheren Artikels zu Facebook nicht wundern, dass auch bei Google eine Art “third-party-partners” (s. den Link unten) auftaucht – selbige heißen bei Google aber “Third-Party-Subprocessors” und “Affiliates”. Die spielen natürlich auch im Kontext der GA-Daten-Erfassung eine interessante Rolle. Letztere wiederum lässt sich allerdings nur über weitere sekundäre (und lange) Dokumente erschließen. Ehrlich: Das nervt!… schon auf Englisch, es würde das aber sicher auch auf Deutsch tun.

Mir scheint, die EU GDPR hat offenbar durchaus das Potential, das Geschäftsmodell bestimmter Informationskraken durch eine bessere Information von Nutzern in Frage zu stellen – und die Anwälte von Facebook, Google und Co. leisten nun ganze Arbeit, um Otto-Normal-Verbraucher mit wirklich schwer verdaulichen Text-Kaskaden von bestimmten Schlussfolgerungen abzuhalten. Gewollt oder nicht …

Im Fall von Google Analytics stößt man dann noch auf eine spezielle Anforderung: Man muss zustimmen, dass Google das Recht hat, Daten aus dem EWR/EU-Raum heraus zu befördern – speziell in die USA. Ich habe das mit meinen begrenzten Englisch-Kenntnissen zumindest so verstanden und meine, Punkt 10.1 ff. der neuen Google-“Terms” lässt hier keine andere Interpretation zu. Dieser Datentransfer dient dann u.a. der Versorgung von “Googles “Affiliates and Subprocessors” in solchen Staaten außerhalb der des EWR/EU-Raums. Dem soll ich als Google-“Customer” zwingend zustimmen.

Tja Leute, warum sollte ich das angesichts einer sich abschottenden amerikanischen Wirtschaft eigentlich tun?

Und ehrlich gesagt, die Termini “Affiliates” und “Subprocessors” gefallen mir gar nicht … speziell, wenn ich für ein besseres Verständnis noch weitere Papiere und Bedingungen studieren soll. Durch einen späteren Abschnitt und durch Appendix 1 wird übrigens klar, dass die exportierten Daten dann natürlich auch die erfassten Daten der Besucher einer Website umfassen. Zumindest nach meinem Verständnis. Vielleicht sollte google dazu mal Stellung beziehen.

Klar auch, dass in dem Augenblick, wo die Daten Server auf amerikanischem, chinesischem, russischem oder sonstigem Nicht-EU-Boden erreichen, dort womöglich der lokalen Rechtsprechung bzgl. des Umgangs mit
unseren/euren Daten unterliegen.

Konsequenz 3

Die neuen Nutzungsbedingungen von Google kann ich nicht guten Gewissens und schon gar nicht ohne vorherige Anwaltskonsultationen mittragen. Der ganze Text ist eine einzige Zumutung. Entscheidend ist dabei aber, dass es hier nicht nur um meine, sondern auch um eure Daten geht.

Liebes Google: Verlangt vom Nutzer eures GA-Services in Zukunft lieber eine angemessener Gebühr und haltet dafür die Daten dann ausschließlich auf EU-Servern vor. Und gebt sie (dann) explizit und grundsätzlich nicht an “Affiliates und Third Party Sub-Processors” weiter! Bitte sucht euch gefälligst auch Übersetzer, die das zugehörige Anwalts-Englisch in klare, für jeden Kunden nachvollziehbare Landessprache übersetzen.

Es ist für mich – wie bei Facebook auch – leider überhaupt nicht nachvollziehbar, was mit meinen und den erfassten Daten meiner Leser passiert, sobald diese Daten – offenbar absehbar und gewollt – die EU verlassen. Sorry, aber dabei gehe ich angesichts der Entwicklung in einigen Staaten weg von demokratisch verfasster Rechtsstaatlichkeit zunächst mal vom Schlimmsten aus. Gegenüber Eingriffen staatlicher Eingriffen nützt nämlich auch eine ISO 27000 nichts, auf die Google hinweist.

Da mein Cookie-Banner aus rechtlichen Gründen natürlich auch auf Google Analytics hinweisen müsste, sehe ich als Voraussetzung einer nachfolgenden aktiven Zustimmung des Lesers auch das Verständnis der Folgen einer Akzeptanz von GA-Cookies als zwingend notwendig an. Nun verstehe ich aber nicht mal selbst Googles Bedingungen … Das kann ich meinen Lesern nicht zumuten.

Der einwöchige Testlauf hat zudem deutlich gezeigt, dass zumindest die Leser dieses Blog die angeforderte explizite Zustimmung wohl aus guten Gründen nicht geben wollen und werden – was ich sehr gut verstehe!

Fazit

GA wird nach der DSGVO faktisch völlig sinnlos, wenn man mit seinen Lesern und potentiellen Kunden fair umgehen will – und eine explizite Zustimmung zu Cookies zur Bedingung für das Ablaufen wenn GA-Scripts macht. Ist vielleicht gut so, denn die Folgen der neuen Bedingungen für die Nutzung von GA kann ein Webseitenbetreiber eigentlich nicht ohne aktives Involvieren seiner Leser mittragen. Und meine Leser haben mir im Laufe der letzten Woche hierzu eine eindeutige Antwort gegeben.

Deshalb stellen wir Google Analytics auf diesem Blog im Interesse unserer Leser ab. Das entsprechende Konto bei GA wurde gekündigt. Leider behält sich Google das Recht vor, im Sinne von staatlich verordneter Datenvorratshaltung die bislang erfassten Daten noch eine Weile vorrätig zu behalten. Auch ein interessanter Punkt – aber ich mag meinen Blutdruck nicht weiter strapazieren …

Gerne könnt ihr mich per E-Mail zu diesem Thema kontaktieren.

Hinweis: Dieser Beitrag wurde am 08.05.2018 und 15.05.2018 textlich und inhaltlich bearbeitet. Am 15.05. wurden zudem etliche Rechtschreibfehler beseitigt.
Eränzung 15.05.2018: Möglicherweise fand der Beitrag ja auch bei Google-Mitarbeitern Interesse. So hatte ich am 07.05.2018 und am 08.05.2018 mehrfach Zugriffe auf mein Xing-Profil von Google-Mitarbeitern zu verzeichnen. Anonym natürlich … Liebe Leute von Google, wenn es etwas zu sagen oder zu besprechen gibt oder ich mich gar bzgl. der neuen Nutzungsbedingungen getäuscht haben sollte, dann schreibt mich bitte unter Nennung von Namen an. Ich bin auch gerne bereit, eure Meinung hier zu präsentieren.

Links

Leaving Facebook … – I
Bruce Schneier über Facebook, Cambridge Analytica und die Daten-Sammel-Industrie
https://www.kuketz-blog.de/das-kranke-www-stop-using-google-web-services/
https://traffic3.net/wissen/webanalyse/google-analytics-datenschutz
https://www.blogmojo.de/google-dsgvo/#5_google_analytics

PHP, MariaDB, Load Data Infile – manchmal ist der Umweg über Dateien performanter ….

Posted on by

Im Moment bin ich wider mit LAMP-Entwicklung beschäftigt. Mit Simulationen zu technischen Netzwerken in mehreren Dimensionen mit vielen Knoten, die kreuz und quer verbunden sein können. In solchen Netzen gibt es u.U. eine mit der Knotenmenge exponentiell wachsende Anzahl von Pfaden. Die Simulation des Informationstransports durch solche Netze ist ähnlich zum Transport von Signalen in “künstlichen neuronalen Netzwerken” – in unserem Fall ist aber die Komplexität aufgrund der Netzstruktur und der Qualität der transportierten Information erheblich größer.

Das Ziel meiner Auftraggeber sind datenbankgestützte Simulationen solcher technischen Netze mit PHP. Bei einer hinreichenden Anzahl von Knoten, Ebenen und Verbindungen erhält man dabei u.U. erhebliche Datenmengen, die man während der laufenden Rechnung systematisch auslagern muss. Das ist in Forschungslabors mit einer Armada von Prozessoren und SSDs nun heute selten ein grundsätzliches Problem. Im einem kleinen Büro oder auf billigen LAMP-Servern aber sehr wohl – insbesondere dann, wenn man nicht mit Multithreading in Web-Server-Umgebungen beginnen will oder aus Sicherheitsgründen gar nicht kann (pthread etc,. lassen das in Webumgebungen gar nicht zu). Oft hilft dann ein kleiner Umweg – und der führt u.U. über Ajax, Web-Clients und Dateien.

Ausgangslage

Aus bestimmten Gründen sollen die Berechnungen meiner Kunden auf LAMP-Servern angeboten werden. Hochgradige Programm-Effizienz ist also ein Muss. Günstige virtualisierte Mittelklasse-Server haben oft eine Ausstattung mit 4-6 Prozessoren, mehreren GB RAM und SSD-Speicherplatz. Zwei Prozessoren sollen ggf. einen Apache-Server mit PHP-Modul stützen, zwei andere eine Hauptdatenbank, die während der Simulation benutzt wird, und ein fünfter ggf. eine Bank für Ergebnisdaten.

Nun macht jeder mal die Erfahrung, dass Datenbank-INSERTs in der Regel grundsätzlich zu den langsamen Transaktionen zählen. Zudem behindern sie in einem PHP-Programm die Ausführung weiterer datengenerierender Funktionen, die möglicherweise gar nicht – oder zumindest nicht zeitnah – von den erzeugten Outputdaten abhängig sind. So kann es je nach Breite von Records schon mal im Bereich von Sekunden dauern, wenn man mehrere hunderttausend Datensätze “on the fly” in Datenbank-Tabellen schreiben will – und dabei auch noch mehrere Indices aufgebaut werden sollen. Wertvolle Zeit, in der andere Dinge – nämlich weitere numerische Berechnungen – passieren könnten. Wie kann man da CPU-Zeit sparen bzw. sinnvoll nutzen?

Ajax und der Web-Client zur Multitasking-Steuerung für Arme

Man vergisst oft, dass bei gut separierbaren Aufgaben auch der (Web-) Client ins Spiel gebracht werden kann. So kann ein Client über Ajax zwei (oder mehr) PHP-Threads auf einem Apache-Server starten – jeder in einer eigenen Umgebung (memory-, session- und prozess-bezogen). Per Ajax kann man den zweiten Prozess auch periodisch – und in Abhängigkeit von zwischenzeitlich dokumentierten Ergebnissen des kontinuierlich laufenden ersten Prozesses starten.

Der Hauptprozess – in unserem Fall unsere Simulation – kann dabei mit den weiteren periodisch gestarteten Prozessen signalartig über ein gemeinsames Medium kommunizieren – nämlich über spezielle Tabelleneinträge in der Datenbank. Die periodischen Jobs lesen diese Information aus und verhalten sich entsprechend. Ergebnisse werden per Ajax an den Client übermittelt, der dann weitere Nachfolgeaktionen einleitet.

Diese Art von getriggertem “Multitasking” über einen zentralen Web-Client und einen vermittelnde Ajax-Schicht hat einige Vorteile bei langwierigen Prozessen – wie etwa Simulationsläufen. Eine typische Anwendung ist etwa das Status-Polling zum Simulationsprozess. Ich hatte darüber bereits früher in diesem Blog berichtet.

Umgang mit großen zwischen-zeitlich aufkommenden Ergebnisdaten

Wie können wir das nun nutzen, um
zwischenzeitlich produzierte große Datenmengen halbwegs schnell in eine Datenbank aufzuräumen? Man vergisst im LAMP-Geschäft zu oft Dateien als Austauschmedium und als Puffer. MariaDB/MySQL-Systeme bieten zudem einen hochgradig effizienten Weg an, große Datenmengen in flache Tabellen einzulesen, nämlich “LOAD DATA INFILE”:

Vergleicht man die Zeit, die man in einem ausreichend mit RAM gepufferten System mit Write-Caching auf Linux-Ebene benötigt, um strukturierte Daten in ein File zuschreiben, so wird man feststellen, dass das u.U. erheblich (!) weniger Zeit kostet, als zwischenzeitlich eine Datenbanktabelle zu befüttern. Das gilt auch dann noch, wenn man die Zeit hinzurechnet, die ein LOAD DATA INFILE der MariaDB für das Füllen einer Tabelle aus den insgesamt generierten CSV-Filedaten (mit ggf. Millionen Datensätzen) benötigt. Das Schreiben in ein File, das anschließende Laden in eine Tabelle einer ansonsten wenig ausgelasteten Bank (ohne gleichzeitige Index-Generierung!) und die nachträgliche Erzeugung von Indices ist i.d.R. immer noch um Faktoren schneller als der direkte Transfer über (prepared) INSERTs – selbst wenn man hunderte Rows in ein INSERT-Statement packt. Zeit, die – wie gesagt – vom eigentlichen Simulationsprogramm genutzt werden kann!

Hinweis:
Ganz entscheidend für den effizienten Einsatz von “LOAD DATA INFILE” ist hierbei, alle Indices von der zu befüllenden Tabelle gelöscht zu haben, die Daten zu laden und erst danach die notwendigen Indices zu generieren. In all unseren Tests haben sich hierbei übrigens MyISAM-Tabellen performanter als InnoDB-Tabellen verhalten.

Schrittfolge

Wir werfen kurz einen Blick auf die Schrittfolge (habe leider gerade keine Zeit, schöne Grafiken zu zeichnen):

  • Schritt 1: Der Web-Client startet das Simulationsprogramm “S”, das durchgehend auf der Hauptdatenbank-Instanz arbeitet.
  • Schritt 2: Der Web-Client startet unmittelbar darauf auch noch zum ersten Mal und danach periodisch ein weiteres Programm “O”, das für die Behandlung von Output-Daten zuständig ist (sobald halt welche angefallen sind) und das dazu eine spezielle Tabelle der Hauptdatenbank auf Einträge zu fertiggestellten Output-Dateien abfragt. Der Client startet “periodisch” aber nur dann weitere Jobs vom Typ “O”, wenn er zuvor Statusmeldungen des aktuellen “O”-Prozesses erhalten hat, und sich der aktuelle “O”-Prozess beendet hat.
  • Schritt 3: Der zweite PHP-Prozess “O” widmet sich dann jeweils der zuletzt fertiggestellten Datei, prüft ggf. deren Struktur und übergibt dann die weitere Behandlung an einen LOAD DATA INFILE-Prozess der MariaDB – ggf. einer zweiten separaten Datenbank-Instanz, der eigene Prozessoren und memory-Anteile zugewiesen wurden.
  • Schritt 4: Nach einem erfolgreichen Laden der Daten durch den Prozess “O” beendet sich dieser, nachdem er dem Client noch eine Meldung per Ajax zugeschickt hat.
  • Schritt 5: Der Client startet ein weiteres Mal das für Outputs zuständige Programm vom Typ “O”.
    etc.

Das Ganze dauert so lange, bis vom Hauptprogramm ein “Signal” (per DB-Eintrag) gesetzt wurde, dass kein weiterer Output mehr zu erwarten ist.

Das Vorgehen entspricht einer Art selbstgesteuertem, dynamischen Batch-Processing von Daten auf einem LAMP-Server. Es erfordert ein wenig mehr Programmieraufwand (insbesondere zur Fehlerbehandlung) als ein Standard-Vorgehen im Rahmen eines einzigen Threads – es bringt u.U. aber Faktoren an Performance – solange die Simulation nicht auf Zwischenergebnisse in der Bank warten muss. Letzteres ist bei uns oft genug der Fall.

Wir haben so Programm-Läufe, die in Tests 25 Sekunden dauerten, auf unter 5 Sekunden gebracht. Es
war der Mühe wert – und wir können anderen, die langwierige PHP-Programme für Simulations-Berechnungen auf LAMP-Servern nur empfehlen, eine solche Vorgehensweise an kritischen Engpässen mal als Alternative zu untersuchen.

Zusammenfassung

Fallen bei langwierigen PHP/LAMP-Programmen zwischenzeitlich große Datenmengen an, können diese u.U. ohne Beeinträchtigung des Hauptprogramms parallel durch weitere PHP-Programme einer Behandlung durch eine Datenbank zugeführt werden. Teil der Steuerung kann dabei ein gemeinsamer Ajax-Client sein, der die Ergebnislieferung der verschiedenen PHP-Programme überwacht. Der Datenaustausch zwischen den parallel laufenden PHP-Prozessen erfolgt dabei über die Datenbank, Ajax-Meldungen und Datenfiles. Zur Behandlung großer Datenmengen kann dabei LOAD DATA INFILE seine Performance-Vorteile ausspielen. Insgesamt sind dadurch im Einzelfall erhebliche Programm-Beschleunigungen möglich.

phpmyadmin, charts, MariaDB – a strange bug with x-axis value order and ORDER clauses in sub-SELECTS

Posted on by

A customer of mine wants to use phpMyAdmin to create some charts whilst working with a complex database. I recommended a trial with phpMyAdmin and its chart functionality. Unfortunately, this did not always work out as expected:

You may e.g. create an ordered resultset first – with a suitable SELECT and ORDER clause – e.g. to get two columns – an index “i” and associatd values “val”. Rows of the resultset ordered e.g. ASC with the “i”-values. But after using the columns “i” a simple line graph the order on the x-axis may appear different than requested by your ORDER clause.

I have posted this as an issue to the (nice) developers of phpmyadmin – who are working on it :-).

There is a workaround. But what I found more interesting is the cause of the problem, which appears on MariaDB and NOT on MySQL. It has apparently to do with a different handling and interpretation of SQL standards for ORDER clauses in sub-SELECTs! See:
https://mariadb.com/kb/en/library/why-is-order-by-in-a-from-subquery-ignored/

This is of general interest for developers using MySQL or MariaDB-databases. I, myself, was not aware of it. Besides an already different handling of database replication, I regard this point as one more indication for a growing “distance” between both RDBM-systems…

If you stumble across the phpmyadmin-chart problem, see a discussion and a workaround on the following site:
https://github.com/phpmyadmin/phpmyadmin/issues/14239

I also want to explicitly thank M. Jayaratne who supplied me with the valuable information referenced above.