- √ - Ladezeit Cometvisu - rsslog.php

[XueSheng]

Noch ein kurzer Nachtrag zum aktuellen Stand.
Ich habe testweise meine config auf wenige Gruppenadressen (auf einer page) und das rsslog reduziert. Bei dieser Konstellation werden die Werte bereits geladen bevor das rsslog zu sehen ist (so wie es auch sein sollte). Hierbei ist das Verhalten bei svn rev. 1971 und 1972 (subjektiv) identisch.

Nehme ich allerdings meine gesamte config (mit mehreren pages), werden die Werte erst nach dem Laden des rsslog angezeigt (hierbei vergehen von sichtbarwerden der config mit Platzhaltern "-" bzw. "NaN" rund 6-7 Sekunden).

Wenn ich rsslog allerdings aus meta/pulgins entferne, dauert das Laden der Werte nur 1-2 Sekunden.

Die Aussagen scheinen etwas widersprüchlich zu sein... aber für mich hat es den Anschein, dass beim Laden vieler Werte und gleichzeitigem Laden des rsslog noch etwas schief läuft.

Meine Vermutung ist folgende (kann totaler blödsinn sein):
Werte werden auf der ersten (sichtbaren) page abgefragt (jedoch noch nicht angezeigt).
Dann wird rsslog geladen.
Dann werden die Werte auf den übrigen pages geladen.
Dann erfolgt erst die Freigabe zur Anzeige aller Werte.


Config und rsslog.db habe ich an MicHau geschickt.

[XueSheng]

Kannst du vielleicht deine Config und deine RSS-Datei zur Verfügung stellen, gerne auch per PN?

Werde ich tun.

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

# sqlite /etc/wiregate/rss/rsslog.db "SELECT id, title, content, tags, state, strftime('%s', t) AS t FROM Logs ORDER by t DESC LIMIT 20;"

Mit dieser Abfrage erfolgt keine Filterung. Ausführdauer rund 12 Sekunden (entspricht auch der Abfragedauer über das rsslog.php).
Wesentlicher Aspekt ist hierbei das "ORDER by t DESC". Ohne Sortierung und "LIMIT 20" dauert die Abfrage noch keine Sekunde!

Auch ein forceReload=true an die URL angehängt?

Ja, habe ich angefügt. Ändert aber nichts.

[Chris M.]

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!

Auch ein forceReload=true an die URL angehängt?
Das ist bei Tests eigentlich zwingend notwendig. Zumindest wenn man eine Aussage und nicht hoffen möchte..

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)?

Wenn der Appcache geändert wurde: ja - ist extra als Feature eingebaut, sonst müsste man das per Hand machen.

[ctr]

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

[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?

[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]

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]

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).

[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)

[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.

[Chris M.]

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

[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).

[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?

[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

[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ß!