- √ - Ladezeit Cometvisu - rsslog.php

[XueSheng]

Die Cometvisu ist bislang die einzige Visu, die ich im Einsatz habe. Gestört hatte mich bislang die lange Ladezeit, die bei mir bis zu einer Minute beträgt.
Da ich noch einige "Dummy Gruppenadressen" in der Visu hatte, die eigentlich nicht existieren, dachte ich die lange Ladezeit würde evtl. damit zusammenhängen.

Nun habe ich mal im Debug Modus des Firefox geschaut woran es wirklich liegt und bin dabei auf die rsslog.php gestoßen. Ich habe über das rrslog plugin zwei Ereignisanzeigen in der Visu. Folgende Ladezeit erhalte ich in der Debug Konsole des Firefox:

[13:32:03.019] GET http://192.168.5.241/rsslog.php?f=security [HTTP/1.1 200 OK 9584ms]
[13:32:03.022] GET http://192.168.5.241/rsslog.php?f=presence [HTTP/1.1 200 OK 21832ms]

...also für die eine Abfrage 10sec und für die andere 20sec. Das ist schon recht heftig.
Wenn ich die beiden rsslog Plugins aus der Visu werfe, werden auch alle Status Anzeigen (info, button, etc.) direkt angezeigt, anstatt ewig den Platzhalter "-" zu zeigen.

Könnt Ihr die langen Ladezeiten bei Verwendung des rsslog Plugins bestätigen? Seht Ihr hier Optimierungsmöglichkeiten?

[Chris M.]

Ohne auf's konkrete Problem zu gehen erst mal ein paar grundlegende Fragen:

• SVN oder Release (Candidate) - welcher?
• Wenn SVN: passiert das auch beim aktuellen Release Candidate?
• Lädt die ganze Seite nicht - oder nur die Werte? Was ist mit den RRD Graphen?
• Wie voll ist die RSS-Datenbank?
  Hast Du mal alte Einträge gelöscht und dann optimiert?

[XueSheng]

• Version: svn rev. 1971
• RC nicht getestet
• Die Seite selbst läd, nur die Werte kommen stark verzögert. Anstatt der Werte sind wärend des Ladevorgangs nur die Platzhalter "-" bzw. "NaN" zu sehen. RRD Graphen zeigen nur "loading...". Sobald die Inhalte des rsslog zu sehen sind, läd auch der Rest nach (rsslog scheint das Laden der Werte und der RRD Graphen zu blockieren).
• rsslog.db ist 9,5MB groß. Keine Ahnung wie man alte Einträge löschen kann/soll. Wenn ich in der Cometvisu auf die Einträge klicke, kann ich diese durchstreichen, jedoch löscht das die Einträge nicht.

# ls -lh /etc/wiregate/rss/rsslog.db
-rw-rw-rw- 1 www-data www-data 9,5M 29. Okt 20:30 /etc/wiregate/rss/rsslog.db

[XueSheng]

Wenn ich versuche über den Parameter "r" der rsslog.php Einträge zu löschen, passiert auch nichts.

http://wiregate/rsslog.php?r=1380578400

Müsste so nicht die URL aussehen, wenn man alle alten Einträge bis zum 01.10.2013 löschen will? Beim laden dieser URL erscheint nur eine weiße Seite. Die Datenbank bleibt 9,5MB groß!

[ZeitlerW]

Hallo XueSheng,

ich mach das über ein kleines shell script:

#!/bin/sh
# löschte alles älter als 3 tage und komprimiert
sqlite rsslog.db "delete from Logs where t<date('now','-3 day');"
sqlite rsslog.db "vacuum;"

... wichtig ist das vacuum, sonst wird die Datei nicht verkleinert.

vG
Wolfgang

[ctr]

Korrigiert mich wenn ich falsch liege, aber auch eine 9,5MB SQLite Datenbank sollte sich nicht in einem 10s Lag äußern?!?
Dafür ist es ja immernoch SQL und der übermittelt nur die angefragten Datensätze... Evtl ist ja nur die Abfrage etwas zu großzügig?

[XueSheng]

ich mach das über ein kleines shell script:

#!/bin/sh
# löschte alles älter als 3 tage und komprimiert
sqlite rsslog.db "delete from Logs where t<date('now','-3 day');"
sqlite rsslog.db "vacuum;"

Das werde ich ausprobieren.

Korrigiert mich wenn ich falsch liege, aber auch eine 9,5MB SQLite Datenbank sollte sich nicht in einem 10s Lag äußern?!?
Dafür ist es ja immernoch SQL und der übermittelt nur die angefragten Datensätze... Evtl ist ja nur die Abfrage etwas zu großzügig?

Die Anfrage wird ja im wesentlichen durch tags definiert/gefiltert. Unter dem tag "presence" sind tatsächliche sehr viele Datensätze gespeichert (war ein Logging der Präsenz für Testzwecke). Gäbe es denn eine Möglichkeit die Abfrage der rsslog auf einen Zeitraum zu begrenzen oder alternativ auf die Anzahl Datensätze, die abgerufen werden?

Ansonsten hilft wohl nur das Aufräumen der Datenbank über ein wiregate Plugin oder über einen cron job (siehe Skript von Wolfgang).

[Chris M.]

Das RRSLog hatte ich mal vor Ewigkeiten entworfen, da darf gerne jemand Datenbank affines mal drüber optimieren

[Chris M.]

• Die Seite selbst läd, nur die Werte kommen stark verzögert. Anstatt der Werte sind wärend des Ladevorgangs nur die Platzhalter "-" bzw. "NaN" zu sehen. RRD Graphen zeigen nur "loading...". Sobald die Inhalte des rsslog zu sehen sind, läd auch der Rest nach (rsslog scheint das Laden der Werte und der RRD Graphen zu blockieren).

OK, dann ist das kein Darstellungproblem o.ä., sondern ein Priorisierungs-Problem beim dynamischen Laden.

=> Nun kann man gezielt suchen - ich werd's vorm Release aber wohl nicht schaffen.

Schaun wir außerdem mal, was das Datenbank-Bereinigen bringt.

[ctr]

Würde es evtl Sinn machen die max-größe der Abfrage zu limitieren ("LIMIT" in den SELECT, siehe: SQLite Query Language: SELECT ), das könnte man ja ggf. auch konfigurierbar ("limit=100") machen oder?

(Das beeinflusst nicht die Dauer der Abarbeitung des Selects, d.h. bei riesigen Datenbanken kann das trotzdem noch ein bißchen beim Select rumrödeln, aber dann müßte es trotzdem nicht mehr in die CV und damit die Verbindung zum Endgerät gepumpt werden. Ich denke die Übertragung und Darstellung im Endgerät ist hier eher der Bottleneck als so eine kleine SQLite Abfrage am Server)

[XueSheng]

rsslog.php verwendet bereits "LIMIT 100". Wenn ich mit diesem Wert spiele (z.B. auf 20 setze), ändert sich nichts an der Dauer der Datenbankabfrage (wie bereits von ctr angemerkt/vermutet).
Die Dauer, die die CometVisu zur Verarbeitung benötigt, kann ich zwar adhoc nicht im Debugmodus sehen, jedoch kann ich subjektiv keinen merklichen Unterschied zwischen LIMIT 100 und 20 erkennen.

Ich habe nun einfach den einen rsslog Eintrag aus meiner Visu geworfen, den ich zu Testzwecken drin hatte (entspricht dem Großteil der Dateneinträge in der Datenbank). Nun dauert die Datenbankabfrage "nur" noch ca. 2-4 Sekunden, obwohl ich keine Einträge aus der Datenbank gelöscht habe. Welchen Einfluss nun das Löschen der Daten aus der Datenbank hat, habe ich noch nicht genauer untersucht.

Mit dem Ergebnis kann ich zumindest mittelfristig leben (daher für mich gelöst).

[MicHau]

Ich habe soeben einen Fix ins SVN eingespielt, der das Problem des verzögerten Ladens beheben sollte.

Kannst du das bitte noch mal prüfen? Eigentlich sollte es jetzt so sein, dass die Visu erst einmal vollständig geladen wird und auch die Werte zu sehen sind. Der Inhalt dess RSSLog Plugins müsste mit Verzögerung geladen werden.

[XueSheng]

Habe nun auf svn rev. 1972 geupdated. Allerdings hat sich am Ladeverhalten nichts geändert. Zuerst wird das rsslog geladen, dann erst die sonstigen Werte. Den Browser Cache habe ich geleert!

OT: Ist es eigentlich normal, dass die Seite nach dem Leeren des Browser Cache zwei Mal läd (Seite baut sich auf, bis alle Elemente geladen sind und dann erfolgt nochmals ein Refresh und die Seite läd ein zweites Mal)?

[MicHau]

AW: - √ - Ladezeit Cometvisu - rsslog.php

Allerdings hat sich am Ladeverhalten nichts geändert. Zuerst wird das rsslog geladen, dann erst die sonstigen Werte.

Tja, das war ein Schuss ins Blaue. Leider habe ich kurzfristig keine Testmöglichkeit mangels RSS. Kannst du vielleicht deine Config und deine RSS-Datei zur Verfügung stellen, gerne auch per PN?

[ctr]

Kannst Du mal das Ladeverhalten außerhalb der CV testen? Also mit sqlite auf der shell?