Statistik aus, trotzdem monatliche Statistik-Archivierung

[djand]

Hallo,

kaum registriert - schon falle ich mit der Tür ins Haus.

Mir ist aufgefallen, dass die Funktion statsArchive() aus dem Cronjob move_old_stats.php ausgeführt wird, obwohl ich die Statistik im System komplett deaktiviert habe. Ist das Absicht?

Diese Funktion löst bei uns jeweils zum Monatsende/Monatsanfang einen kompletten Systemcrash aus. Das Frontend ist nicht mehr erreichbar, bis man den Server neustartet.

Gibt es eine simple Lösung, dieses Problem zu beheben/umgehen? Normal ist es ja nicht, dass das System durch diese Funktion den Geist aufgibt. Wäre es eine Lösung, die Funktion statsArchive() in der Datei move_old_stats.php auszukommentieren, oder gibt es dadurch erhebliche Nachteile?

Viele Grüße
djand

[frederic.schneider_4fb]

Lieber djand,

herzlich Willkommen im Forum! Das ist sehr ärgerlich, dürfte nicht passieren und ist etwas, das wir uns auch mal zeitnah ansehen werden. Grundsätzlich: Wenn Du keinerlei Wert auf die CONTENIDO-seitige Statistik legst, kannst Du auch einfach die Ausführung des Cronjobs verhindern. Hierzu kannst Du im Plugin Manager (Administration -> Plugin Manager) das Plugin "Cronjobs Overview" installieren. Das taucht nach einem Neuladen des Backends unter dem Tab "Administration" auf. Über "Cronjob bearbeiten" kannst Du die Zeile

Code: Alles auswählen

0 0 1 * * move_old_stats.php

entfernen. Das hat die gleiche Wirkung wie wenn Du den Funktionsaufruf aus dem Cronjob entfernst, nur dass der Cronjob erst gar nicht mehr aufgerufen wird. Ohne den Funktionsaufruf tut der Cronjob nämlich außer bisschen Selbstverwaltung und etwas Kleinkram nichts Sinnvolles.

Eine Frage:
Ihr habt sehr viele Artikel/Besucher/Klicks auf Eurer Seite, oder? Die Funktion ist nämlich dafür zuständig, für den betreffenden Monat für alle Artikel/Seiten neue Einträge zu machen und alte zu entfernen. Wenn das zigtausende Einträge pro Monat sind, kommt da freilich eine richtige Menge zustande, was je nach Auslastung und Ausstattung eines Servers durchaus zu den Problemen führen könnte. Wir schauen uns das an, wie wir das optimieren können.

[djand]

Vielen Dank für ihre rasche Antwort und Ihre freundliche Unterstützung.

[mattmarr]

Hallo Frederic,

... "Cronjobs Overview" installieren. Das taucht nach einem Neuladen des Backends unter dem Tab "Administration" auf. Über "Cronjob bearbeiten" kannst Du die Zeile

Code: Alles auswählen

0 0 1 * * move_old_stats.php

entfernen. Das hat die gleiche Wirkung wie wenn Du den Funktionsaufruf aus dem Cronjob entfernst, ...

Das Deaktivieren ist ja schön und gut.
Aber es wird trotzdem in der Tabelle '*_stat' ein Eintrag vorgenommen.
Bei vielen Besuchern, auch viele Eintrage.
Da kann die Tabelle schon mal schnell an ihre grenzen kommen.

Was mir in der Datei "includes/functions.stat.php", Zeile 93(https://api.contenido.org/con4911/sourc ... tml#65-108), auch aufgefallen ist.
Warum wird nach der Verarbeitung der Daten, durch move_old_stats.php, in '*_stat' ein DELETE gemacht und nicht kein TRUNCATE? Durch das benutzen von DELETE steigt die Gefahr, das die Spalte IDSTAT an ihre grenzen kommt.


Gruß
Matthias

[frederic.schneider_4fb]

Lieber Matthias,

das ist richtig. Aber djand hat sich ja darüber beschwert, dass das Ausführen des Cronjobs zu den erheblichen Problemen führt. Dann werden nämlich auf einmal Hunderte Datenbankeinträge geschrieben. Alles eine Frage der Lastenverteilung . Es ist perspektivisch aber die Frage, inwieweit wir diese Onboard-Statistik überhaupt noch benötigen und ob es nicht klüger wäre, auf etablierte Systeme zu setzen - mal als unabgesprochener Gedanke meinerseits.

[mattmarr]

Lieber Frederic,

Es ist perspektivisch aber die Frage, inwieweit wir diese Onboard-Statistik überhaupt noch benötigen und ob es nicht klüger wäre, auf etablierte Systeme zu setzen - mal als unabgesprochener Gedanke meinerseits.

Kurz und knapp:
raus damit!
Wurde von mir in den vielen Jahren noch nie benötigt. Ich denke anderen geht es genauso.


Grüße

[frederic.schneider_4fb]

Guten Tag allesamt,

ich habe meinen Wunsch intern angebracht, die Statistik komplett zu entfernen. Wir werden diesen Schritt aber erst einmal nicht in Gänze gehen, da es wohl Nutzer gibt, die die Statistik noch verwenden. Stattdessen etablieren wir die Möglichkeit, die Statistik systemweit zu deaktivieren. Standardmäßig ist die Statistik deaktiviert. Damit bleibt zwar - vorerst - der gesamte Code vorhanden und auch das Cronjob wird ausgeführt - im deaktivierten Zustand aber direkt wieder abgebrochen. Im deaktivierten Zustand wird zukünftig im Frontend auch nichts mehr getrackt. Bei einer frischen Installation wird es nach der Erstinstallation also keine Veränderungen mehr an den beiden Statistik-Tabellen geben, außer der Nutzer aktiviert die Statistik ausdrücklich unter Administration -> System -> Konfiguration. Diese Implementierung funktioniert ab der CONTENIDO-Version 4.9.13, nach einer Neuinstallation oder einem Upgrade. Im Git sind die Änderungen bereits eingepflegt.

Hinweis:
Es gab bislang schon die Möglichkeit, die Statistik mandantenweise zu deaktivieren. Das ist sicher mal sinnvoll gewesen, ist aber in der Gesamtbetrachtung nicht mehr passend. Deshalb werden diese mandantenweisen Deaktivierungen auch ab der CONTENIDO-Version 4.9.13 keinen Effekt mehr haben und bei einem Upgrade auch entfernt. Die Statistik lässt sich nur noch systemweit deaktivieren/aktivieren.

Wir werden in den Hinweisen zu der neuen Version darauf hinweisen, dass auch nach einem Upgrade die Statistik deaktiviert wird und keine Besucherzahlen mehr getrackt werden.

In diesem Zuge habe ich der Anregung von mattmarr entsprechend den "DELETE FROM"-Befehl durch ein "TRUNCATE TABLE" ersetzt, was etwas schneller ist. Des Weiteren ist in dem Kontext noch ein Fehler in der statsArchive-Funktion behoben worden.

[Faar]

Wir werden in den Hinweisen zu der neuen Version darauf hinweisen, dass auch nach einem Upgrade die Statistik deaktiviert wird und keine Besucherzahlen mehr getrackt werden.

Konnte denn die Statistikfunktion echte Besucher von Robots unterscheiden?

In diesem Zuge habe ich der Anregung von mattmarr entsprechend den "DELETE FROM"-Befehl durch ein "TRUNCATE TABLE" ersetzt, was etwas schneller ist.

Ganz massiv sogar schneller, wenn die Tabelle wirklich groß ist. Ein "delete from ... where" kann dann einen schnellen Server für längere Zeit zum stehen bringen.

[frederic.schneider_4fb]

Wir werden in den Hinweisen zu der neuen Version darauf hinweisen, dass auch nach einem Upgrade die Statistik deaktiviert wird und keine Besucherzahlen mehr getrackt werden.

Konnte denn die Statistikfunktion echte Besucher von Robots unterscheiden?

War das eine rhetorische Frage? Die bisherige Statistik hat schlicht und ergreifend für jeden einzelnen Artikel die Klickzahlen gezählt, darüber hinaus lässt sich das im Backend nach Monaten unterscheiden. Perspektisch wäre es womöglich sinnvoller, ein etabliertes Statistiksystem als Integration anzubieten.

[Faar]

Nein, die Frage war schon ernst gemeint. Ich hatte mich nie um diese Statistik gekümmert, weil ich selbst weiß wie schwer es ist, Klickzahlen von Besuchern und Robots zu unterscheiden.
Wenn nur Klickzahlen gezählt werden, könnt ihr das gleich raus werfen, das macht keinen Sinn. Dann lieber Plugins oder Module, die helfen, Tracking-Software oder Tools einzubinden.
Die Datenbank wird sonst tatsächlich unnütze belastet.

[frederic.schneider_4fb]

Deshalb ist die Statistik nun standardmäßig deaktiviert und belastet somit auch die Datenbank nicht mehr kontinuierlich. Wie ich mir das perspektisch vorstelle, habe ich ja bereits geschrieben. Das gehen wir allerdings nicht mehr kurzfristig an, wir möchten ja bald die neue Version veröffentlichen