PHP Warnings im Log

[pichel]

Hallo André,

danke für die Leistungsdaten. Alles, was das csv enthält, lässt sich auch in der Webansicht anzeigen, wenn man den Filter entsprechend setzt (die drei Einstellungen: Aktion, TSE, Localhost), und dann auf Update klickt.

Ich habe deine Messwerte mit dem Durchschnitt der Daten verglichen, die ich in der ersten Woche nach dem Release mit der Telemetrie von den Anwendern, die der Übermittlung zugestimmt haben, erhalten habe (diese Werte sind im PDF-Handbuch in Kapitel 2.73 ab Seite 170ff. veröffentlicht). Da war die Anzahl der beteiligten Gastronomen jedoch noch sehr klein und wenn ich jetzt nochmal die Mittelwerte bilden würde, könnten sich die Ergebnisse noch ändern. Trotzdem zeigt sich, dass dein System zwar kein schlimmer Ausreißer nach oben ist, aber auch nicht besonders schnell.

Es bleibt also die Frage, warum es bei einigen Aktionen so langsam arbeitet.

Beim letzten Versionsupdate ist nicht viel passiert:
- Die Dateien werden heruntergeladen. Wenn das besonders lange gedauert hat, würde ich auf eine Firewall tippen.
- Im Anschluss wird das Datenbank-Update durchgeführt.

Bei letzterem Schritt ist seit 2.3.0 herzlich wenig passiert:

Code: Alles auswählen

        public static function upd_2300_2301($pdo, $prefix, $dbname) {
                return array(true);
	}
        public static function upd_2301_2302($pdo, $prefix, $dbname) {
                return array(true);
	}
        public static function upd_2302_2303($pdo, $prefix, $dbname) {
                return array(true);
	}
        public static function upd_2303_2304($pdo, $prefix, $dbname) {
                try {          
			return array(true);
		} catch (PDOException $e) {
			return array(false,$e->getMessage());
		}
	}

Die Funktion createClosingCore in closing.php ist sehr lang, kompliziert und würde eigentlich dringend ein Refactoring benötigen. Trotzdem wäre es sicherlich interessant zu sehen, wo es hakt. Man könnte also in der Funktion ein paar error_log Anweisungen einbauen, oder ganz generell mal temporär in CommonUtils.php bei jedem Aufruf einer SQL-Query die Zeiten messen (inkl. Ausgabe der SQL-Query im error_log). Würdest du dir das zutrauen und prüfen, welche der Anweisungen besonders lange braucht.

Gruß,

Stefan

[misery]

Moin Stefan,

ich habe ein wenig das System angesehen. In der VM selbst ist so gut wie kein CPU/IO, Wenn ich auf dem Hypervisor (Synology) sehe, sehe ich ständig 500-1000 kb IO (nicht CPU) auf einem kworker. Das ist jetzt auch nicht unbedingt etwas, was das System in die Knie zwingt. Ich habe bei mir im Keller eine ältere DS218+ stehen, auf dem UM WEITEN mehr läuft und keinerlei Performance-Probleme hat.

Wie auch immer, wenn ich den Printserver auf dem anderen Rechner STOPPE, fällt die Last vom kworker auf fast nix runter. In der VM habe ich dann mal den nginx das access_log deaktiviert - da kommt zwar auch kaum etwas an - aber ein Versuch ist es wert. Aber nein, das war es auch nicht. Die Sachen, die das System schreibt, ist ein Witz.
Die Last kann ich mir nicht erklären wieso ein 3-Sekunden Polling so eine Last auf dem kworker verursacht.

Ich benutze deinen Auto-Updater in der Admin nicht. Ich mache das immer komplett von Hand.
Ich denke nicht, dass es an der 2.3.3 liegt. Die Versionen davor haben sicherlich das gleiche Problem.

Ich überlege gerade die VM gegen Docker zu ersetzen. Aber das ist nicht mal eben so und birgt auch einiges an Risiko und Verlust von Komplett-Backups des Systems. Hast du eventuell schon ein Docker-Compose, der Apache, TSE und Mariadb als eigene Container spawnt?

Mh, ich kann ja mal reinsehen in die Datei.


André

[pichel]

Hallo André,

Docker wäre wahrscheinlich in deinem Fall einen Versuch wert.

Als Docker-Image kannst du jedes LAMP-Image nehmen und htdocs reinmounten und natürlich die DB (üblicherweise über Environment-Variablen) vorbereiten, damit der Installer vernünftig arbeiten kann. Ein vorbereitetes Docker-Image mit einer bereits vorinstallierten Installation kann ich dir gerade nicht anbieten, aber es sollte reichen, wenn man das ubuntuinstaller-script (ohne die Benutzerabfragen) als entrypoint einhängt, bzw. muss das Skript dann beim Aufruf testen, ob die DB schon existiert und wenn ja, dann es sich nicht ausführt und beim Containerstart bestehende Daten wieder überschreibt.

Gruß,

Stefan