Timeout bei Statistikabfrage
Timeout bei Statistikabfrage
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
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
-
- Beiträge: 3626
- Registriert: Di 12. Okt 2004, 20:00
- Wohnort: Voerde (Niederrhein)
- Kontaktdaten:
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.
=> 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.
@dodger77: Danke!
.job-Dateien auf 644
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.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.
Verzeichnis steht auf 755=> Berechtigungen überprüfen
.job-Dateien auf 644
((Wie sags ich's meinem Kunden? ))... Tabelle leeren... Dadurch gehen natürlich die archivierten Statistiken verloren.
-
- Beiträge: 3626
- Registriert: Di 12. Okt 2004, 20:00
- Wohnort: Voerde (Niederrhein)
- Kontaktdaten:
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.ippkem hat geschrieben: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.
Das muss nicht ausreichen, evtl. ist 777 und 666 notwendig, je nachdem, wie der Webhoster den Indianer konfiguriert hat.ippkem hat geschrieben:Verzeichnis steht auf 755=> Berechtigungen überprüfen
.job-Dateien auf 644
-
- Beiträge: 5478
- Registriert: Di 2. Mär 2004, 21:11
- Wohnort: Halchter, wo sonst? ;-)
- Kontaktdaten:
Re: Timeout bei Statistikabfrage
Genau das ist auch das Problem.ippkem hat geschrieben:Es läuft derzeit 4.6.15, dass nach und nach von der 4.4.4 upgedatet wurde.
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.
Bitte keine unaufgeforderten Privatnachrichten mit Hilfegesuchen schicken. WENN ich helfen kann, dann mache ich das im Forum, da ich auch alle Postings lese. PN werden nicht beantwortet!
Hallo,
da die Welt klein ist, bin ich in das Problem von ippkem auch involviert und habe mir das mal angeschaut:
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
da die Welt klein ist, bin ich in das Problem von ippkem auch involviert und habe mir das mal angeschaut:
Es gibt hier jeweils mehrere Einträge mit gleicher idcatart/idlang/idclient.Dodger77 hat geschrieben:Normalerweise sollte je Wert von "archived" und "idcatart" nur ein Eintrag vorliegen.
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
Für die Freizeit : www.hobbybrauer.de
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 !!!
Wäre das eine sinnvolle Lösung ??
Danke nochmal !
Tino
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;
Danke nochmal !
Tino
Zuletzt geändert von tinof am Mo 28. Apr 2008, 13:35, insgesamt 2-mal geändert.
Für die Freizeit : www.hobbybrauer.de
-
- Beiträge: 3626
- Registriert: Di 12. Okt 2004, 20:00
- Wohnort: Voerde (Niederrhein)
- Kontaktdaten:
@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.
Damit sollte man alles ab 2007 bereinigt haben. Ob die Daten aber überhaupt sinnvolle Werte haben, ist fraglich.
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
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.
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.
Für die Freizeit : www.hobbybrauer.de
-
- Beiträge: 5478
- Registriert: Di 2. Mär 2004, 21:11
- Wohnort: Halchter, wo sonst? ;-)
- Kontaktdaten:
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.
Bitte keine unaufgeforderten Privatnachrichten mit Hilfegesuchen schicken. WENN ich helfen kann, dann mache ich das im Forum, da ich auch alle Postings lese. PN werden nicht beantwortet!
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
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
Für die Freizeit : www.hobbybrauer.de