Timeout bei Statistikabfrage

[ippkem]

Dass eine gut gefüllte con_stat_archive Probleme bereiten kann, wurde an anderer Stelle behandelt. Dass aber Contenido die Statistik nicht anzeigt, sondern mit einem Timeout ("A timeout occured while waiting for the script output (in: /usr/www/users/NAME/contenido/main.php).") quittiert, habe ich noch nicht gefunden. Die Analyse von knapp 2 Millionen Records scheint demnach zu lange zu dauern. Möglicherweise dient die Zeitbegrenzung auch als severseitige Schutzmaßname.

Wie dem auch sei, der Kunde möchte seine Statistik ansehen. Welche Chancen habe ich

a) Contenido die Anzeige dennoch zu entlocken
b) alternativ die Auswertung lokal und offline vorzunehmen?

Die große Menge an Records ist schon merkwürdig. Sie scheinen nur im Jahr 2007 entstanden zu sein. Durch das Entfernen der Jahrgänge 2005 und 2006 hat sich die Recordanzahl nur um ein paar Zehntausend verringert.

Es läuft derzeit 4.6.15, dass nach und nach von der 4.4.4 upgedatet wurde.

Gruß
Ippkem

[Dodger77]

Die Anzahl der Einträge in der con_stat_archive ist wahrscheinlich nicht richtig. Die Ursache ist i.d.R., dass das Verzeichnis "contenido/cronjobs/" und/oder die darin enthaltenen ".job"-Dateien nicht durch den Webserver geschrieben werden können.

=> Berechtigungen überprüfen

Den Timeout wirst du wahrscheinlich nur dadurch verhindern können, indem die Tabelle con_stat_archive geleert wird (z.B. per phpMyAdmin). Dadurch gehen natürlich die archivierten Statistiken verloren.

[ippkem]

@dodger77: Danke!

Die Anzahl der Einträge in der con_stat_archive ist wahrscheinlich nicht richtig. Die Ursache ist i.d.R., dass das Verzeichnis "contenido/cronjobs/" und/oder die darin enthaltenen ".job"-Dateien nicht durch den Webserver geschrieben werden können.

Heisst das, dass wenn die Berechtigungen falsch gesetzt gewesen wären, in die con_stat_archive immer wieder die selben Daten archiviert worden sind? Dann wäre ja diese Tabelle wertlos. Ich gehe davon aus, dass die physikalische Anzahl korrekt ist, denn die Übertragung der Tabelle ins lokale hat sehr lange gedauert.

=> Berechtigungen überprüfen

Verzeichnis steht auf 755
.job-Dateien auf 644

... Tabelle leeren... Dadurch gehen natürlich die archivierten Statistiken verloren.

((Wie sags ich's meinem Kunden? ))

[Dodger77]

Heisst das, dass wenn die Berechtigungen falsch gesetzt gewesen wären, in die con_stat_archive immer wieder die selben Daten archiviert worden sind? Dann wäre ja diese Tabelle wertlos.

Genauso ist es. Das kann man natürlich mal selbst per phpMyAdmin überprüfen. Normalerweise sollte je Wert von "archived" und "idcatart" nur ein Eintrag vorliegen.

=> Berechtigungen überprüfen

Verzeichnis steht auf 755
.job-Dateien auf 644

Das muss nicht ausreichen, evtl. ist 777 und 666 notwendig, je nachdem, wie der Webhoster den Indianer konfiguriert hat.

[Halchteranerin]

Es läuft derzeit 4.6.15, dass nach und nach von der 4.4.4 upgedatet wurde.

Genau das ist auch das Problem.
http://forum.contenido.org/viewtopic.ph ... tatarchive
Ich habe die mal per Hand bereinigt, wobei ich einen Großteil (wenn nicht gar alle, aber so genau ließ sich das nicht mehr feststellen) der Daten gerettet habe. Ich weiß nicht, wie groß das bei dir ist und wieviel Zeit du zu investieren bereit bist.

[tinof]

Hallo,

da die Welt klein ist, bin ich in das Problem von ippkem auch involviert und habe mir das mal angeschaut:

Normalerweise sollte je Wert von "archived" und "idcatart" nur ein Eintrag vorliegen.

Es gibt hier jeweils mehrere Einträge mit gleicher idcatart/idlang/idclient.
Dabei fällt auf, das immer eine UNMENGE von Einträgen mit visited=0 gibt, und dann noch 5-10 Einträge mit visited - Werten bis zu 20, 30.

Ich würde nun die visited = 0 Einträge löschen, weil die doch irgendwie sowieso sinnlos sind ?

Ich habe mal (schnell) den code durchsucht:
Alle aus meiner Sicht für die Zählung wirklich relevanten Schreibzugriffe auf die con_stat_art fügen dort den Wert visited=1 bzw. visited = visited + 1 ein.
Die einzige Stelle, an der visited = 0 geschrieben wird, ist
conEditFirstTime(), die die Statisitk quasi initialisiert (und davon ausgeht, dass es noch keinen Eintrag gibt - sprich immer wieder neue anlegt)

Ich finde zwar momentan den Zusammenhang zwischen den cronjobs und conEditFirstTime() nicht, aber ich denke, diese Einträge sind nicht relevant.

Gibt es Gegenanzeigen ?

Danke !
Tino

[tinof]

Ich nochmal.

edit: endgültiges Script eingearbeitet.


ACHTUNG: Das Script ist nur für das Problem "viele con_stat_archive Datensätze aufgrund falscher Konfiguration der chron - jobs" gedacht, inwieweit es andere con_stat_archive - Probleme lösen kann muss im Einzelfall geprüft werden.
VORSICHT ! SCRIPT LÖSCHT DATEN ! BACKUP ERSTELLEN VOR AUSFÜHRUNG (wenn es noch geht) ! !!! KEINE GEWÄHR !!!

Code: Alles auswählen

-- mal eine Hilfstabelle fuer diese schwere Arbeit anlegen 
CREATE TABLE tmp_stat_archive 
( 
idstatarch integer AUTO_INCREMENT, 
archived integer, 
idcatart integer, 
idlang integer, 
idclient integer, 
visited integer, 
PRIMARY KEY(idstatarch) 
);

-- diese mit den sinnvollen Saetzen fuellen 
INSERT INTO tmp_stat_archive (archived, idcatart, idlang, idclient, visited) 
SELECT 
archived, idcatart, idlang, idclient, sum(visited) 
FROM con_stat_archive 
GROUP BY archived, idcatart, idlang, idclient;

-- das Original jetzt leeren, incl. allem Muell 
TRUNCATE TABLE con_stat_archive;


-- die con_stat_archive manipulieren damit wir alles gleich in SQL abhandeln können
ALTER TABLE con_stat_archive
MODIFY COLUMN idstatarch integer auto_increment;

-- und die interessanten saetze wieder in die so vorbereitete Tabelle einfuegen 
INSERT INTO con_stat_archive (archived, idcatart, idlang, idclient, visited) 
SELECT 
archived, idcatart, idlang, idclient, visited 
FROM tmp_stat_archive;

-- Originalzustand wiederherstellen
ALTER TABLE con_stat_archive
MODIFY COLUMN idstatarch integer;

-- sequence anpassen
UPDATE con_sequence, con_stat_archive 
SET nextid =  idstatarch
WHERE seq_name = 'con_stat_archive'
AND idstatarch = (SELECT max(idstatarch) FROM con_stat_archive);

-- die wird nicht mehr gebraucht: 
DROP TABLE tmp_stat_archive;

Wäre das eine sinnvolle Lösung ??

Danke nochmal !
Tino

[Dodger77]

@Tino:

Es geht ja hier erstmal um die con_stat_archive und die wird einzig und allein durch den cronjob "move_old_stats.php" geschrieben. Das erfolgt dann durch die Funktion statArchive() in der "contenido/includes/functions.stat.php". Die macht 2 Dinge: ersten schiebt sie die Daten aus der con_stat für den letzten Monat in die con_stat_archive und setzt dann die con_stat zurück.

Ich weiß allerdings nicht, was passiert, wenn man alles mit "visited" = 0 löscht. Sinnvoller ist es per phpMyAdmin folgendes SQL auszuprobieren und dann das Ergebnis zu exportieren. Danach die Tabelle leeren, Dump zurückspielen, fertig.

Code: Alles auswählen

SELECT `idstatarch`, `archived`, `idcatart`, `idlang`, `idclient`, MAX(`visited`), `visitdate` FROM `con_stat_archive` WHERE `archived` > '200700' GROUP BY `archived`, `idcatart` ORDER BY `archived` DESC, `idcatart` ASC, `visited` ASC

Damit sollte man alles ab 2007 bereinigt haben. Ob die Daten aber überhaupt sinnvolle Werte haben, ist fraglich.

[tinof]

Danke @Dodger77 !

Der Cronjob move_old_stats.php kopiert einmal pro Monat (am Ersten um 0:00 wenn ich die crontab.txt richtig interpretiere ?) den Inhalt der con_stats in die con_stats_archive, löscht anschließend die con_stats und legt für jeden Artikel/Lang/Client einen neuen Eintrag an mit visited=0.

Wenn dieser Job 'Amok' läuft, dann erzeugt er immer wieder solche Einträge um sie beim nächsten mal in die stats_archive zu kopieren.

Bei uns war das so, dass der Cronjob mit jedem Seitenaufruf erneut angeschubst wurde.

Die 'richtige' Statisitik hat dann zufällig irgendeinen dieser Einträge weitergezählt, das erklärt das Mehrfach - Auftreten der idcatarts. Eigentlich müße es mehr Einträge mit visited = 1 geben.

Ich habe mal mein Script bis zum Füllen der Temp - Tabelle laufen lassen.
Der Inhalt sieht ganz plausibel aus.

Was solls, ich werde mal mein Script zu Ende laufen lassen; der MySQL Dumper ist jetzt schon das zweite mal abgestorben ....


Schönes Wochenende!
Tino

Edit:
Ich habs gemacht, es gibt Probleme mit dem Rest des scriptes, weil der Primärschlüssel nicht automatisch gesetzt wird in con_stat_archive.
Habe temporär zum Autoinc gemacht , eingefügt und dann die con_sequences angepasst.
Sorry, muss los, am Montag nochmal ausführlicher.

Ergebnis sieht plausibel aus.

[Halchteranerin]

Wie ich im verlinkten Thread geschrieben habe, HABE ich alle Einträge mit visited=0 gelöscht und es ist auf dem ersten Blick nichts Schlimmes passiert. Also mir ist nicht aufgefallen, dass etwas gefehlt hat.

[tinof]

Hallo,

so, habe mein endgültiges Script im obigen Post eingestellt.

Bei uns hat es die Statistik erfolgreich bereinigt (von 16 Mio auf ca. 5000 Datensätze), es kommen jetzt wieder plausible Ergebnisse.

Grüße
Tino

[ippkem]

Vielen Dank, insbesondere an @ tinof!!!

Der Kunde hat seine Statistik jetzt wieder!