Performance-Probleme

[iceman-fx]

Hi,
aktuell braucht der Aufruf der Statistiken im BE (Statistiken oder Seitenaufrufe) bei Webseiten mit vielen Besucher sehr sehr lange (> 15sek.).

Grund liegt wahrscheinlich an den massigen Einträgen, welche in den Tabellen immer komplett geladen werden.
Bsp:
~1500 Einträge bei den Seitenaufrufen
~90000 Einträge bei den Statistiken > Ausstiegsseiten
Und das nur bei Ansicht der letzten 30 Tage.

Wäre es daher nicht sinnvoller, wirklich nur die Anzahl der Daten zu laden, welche auch angezeigt werden, also z.B. 20 Stk. ?
Die anderen kann man dann ja per Ajax oder URL-Aufruf (nach)laden.

Klar ist es aktuell bequem, die Tabelle so schnell neu sortieren und durchschalten zu können (es ist ja alles schon geladen).
Aber bis dahin dauert es gefühlt eine Ewigkeit - erst recht, wenn man dann noch bei den Seitenaufrufe einzelnen URLs entfernen möchten.

[AndiLeni]

@iceman-fx Kannst du mit dem debug addon testen, wie lange die datenbank abfragen dauern wenn die seiten aufgerufen werden?

[iceman-fx]

Sagt Dir dies etwas:

[AndiLeni]

Ja, danke!
Wie viele Tabellenzeilen hat denn rex_pagestats_visits_per_url bei dir?

[iceman-fx]

32 241 (~9 MB)

[AndiLeni]

Mhmm, ich habe gerade bei meiner Seite nachgesehen. Die hat dort knapp 25.000 Einträge, benötigt für die datenbankabfrage aber nur einen Bruchteil der Zeit die bei dir benötigt wird.

Eventuell liegt das Problem eher an der Verbindung zu deiner Datenbank. Ansonsten kann ich mir das Verhalten auf die schnelle nicht erklären ohne tiefere Analyse.

[iceman-fx]

Andere Installationen auf dem gleichen Server, aber mit wesentlich weniger Daten, laden ruckzuck.
Nur bei diesen massiven Daten braucht es lange.

[iceman-fx]

Wo finde ich denn im Code die Stellen, an denen die Menge ausgelesen wird?
Dann könnte ich es mal auf 20 begrenzen und schauen, ob es dann schneller lädt.

[AndiLeni]

Das passiert einmal hier:

statistics/lib/Pages.php

Line 46 in cbb25d9

public function sumPerPage(string $httpstatus): array

in der Funktion
und hier.

statistics/lib/Pages.php

Line 105 in cbb25d9

$list = rex_list::factory("select agg.url, agg.count, IFNULL(us.status, '-') as 'status' from ( select url, IFNULL(SUM(count), 0) AS 'count' from " . rex::getTable("pagestats_visits_per_url") . " WHERE date BETWEEN '" . $this->filter_date_helper->date_start->format('Y-m-d') . "' and '" . $this->filter_date_helper->date_end->format('Y-m-d') . "' group by url) agg left join " . rex::getTable("pagestats_urlstatus") . " us on agg.url = us.url order by agg.count desc", 10000);

Wobei vermutlich der erste Link relevant sein dürfte für dich.

[iceman-fx]

Moin.
Für was wird eigentlich die Tabelle rex_pagestats_sessionstats genutzt?

Diese ist bei mir innerhalb von 8 Monaten bereits auf 160 MB angestiegen und scheint den Aufruf teilweise mit zu bremsen.

[AndiLeni]

@iceman-fx die Tabelle pagestats_sessionstats wird genutzt um die "letzte besuchte Seite", "Anzahl besuchter Seiten" und "Besuchsdauer" pro Sitzung des Besuchers zu erfassen.

[iceman-fx]

Also schon sehr wichtig.

Habe jetzt erst einmal alle Daten die älter sind als 3 Monate aus der DB gelöscht, damit man wieder ins Addon rein kommt.
Vorher gab es einen Abbruch, weil weniger als 270MB memory_limit verfügbar ist und damit die immensen Daten nicht ausgelesen werden können.

[AWqxKAWERbXo]

Hierzu aus #126

Folgende Optimierungen sind auf Datenbankebene möglich:

• Hash-Felder benötigen nicht varchar(255), sondern varchar(40) oder char
• Gleiches gilt für rex_pagestats_sessionstats.token
• rex_pagestats_bot alle varchar-Felder können kürzer
• rex_pagestats_data.type könnte enum/set sein
• rex_pagestats_sessionstats.visitduration und .pagecount könnten int(5) unsigned oder kleiner sein
• rex_pagestats_referer.referer könnte vermutlich kürzer sein varchar(255), die Information wird praktisch nicht benötigt, wenn im Wesentlichen die Domain interessant ist.
• rex_pagestats_urlstatus.status könnte varchar(24) sein oder nur int(3) unsigend für den HTTP-Statuscode