Hallo Rudolf,
mit FW_closeInactiveClients() wird in FHEMWEB alle 60 Sekunden mit inaktiven Verbindungen aufgeräumt. Dazu gab es auch mal einen Thread mit ständig wachsender Anzahl an Verbindung, weil mit irgendwas speziellerem Verbunden, meine ich.
Nun fällt dieser Timer bei mir in apptime mit ca. 200ms Laufzeit oder mehr auf, wenn er die Browserverbindungen mangels meiner Inaktivität aber unnötigerweise aufräumt.
Ich habe für meine FHEMWEB Instanz einen refresh von 600 Sekunden eingestellt. Damit werden die Verbindungen zwangsläufig gekillt, wenn keine Aktivität meinerseits oder notify Updates passieren (ich nutze Firefox).
Es wäre schön, wenn dieses Aufräumintervall via global Attribut einstellbar wäre, denn wenn ich das Intervall nebst Inaktiviätstimeout im FHEMWEB Code auf 660 Sekunden hoch setze, dann bleiben die ja noch genutzten Verbindungen am leben und die Laufzeit von FW_closeInactiveClients() fällt auf rund 25ms.
Wenn Du schon dabei wärest, eine kleine Optimierung beim Zugriff auf die hashes senkt diese Laufzeit weiter auf etwa 12ms bei mir:
sub
FW_closeInactiveClients()
{
my $now = time();
my $h;
foreach my $dev (keys %defs) {
$h = $defs{$dev};
next if( !defined($h->{TYPE})
|| $h->{TYPE} ne "FHEMWEB"
|| $h->{inform}
|| !$h->{LASTACCESS}
|| ($now - $h->{LASTACCESS}) < 659);
Log3 $FW_wname, 4, "Closing inactive connection $dev";
FW_Undef($h, undef);
delete $defs{$dev};
delete $attr{$dev};
}
InternalTimer($now+660, \&FW_closeInactiveClients, 0, 0);
return;
}
Für eine Aufräumintervalleinstellung fällt mir erst mal nur ein globales Attribut ein, da die Funktion ja eine Modulfunktion ist und nicht durch eine Instanz gesteuert.
Ein gutes Neues, danke und Gruß,
Ansgar.
Verstehe ich dich richtig: die Laufzeit eines Aufrufs verringert sich von 200ms auf 25 nur dadurch, dass man es seltener Aufruft?
Wenn ja, dann ist vmtl. removeFromNtfyHash() die Ursache, und durch seltener Aufrufen schiebt man das Problem nur aus FW_closeInactiveClients raus, weil dann diese Zeit beim clientseitigen Schliessen der Verbindung verbraucht wird.
Die andere Optimierung habe ich uebernommen, ist wohl eher auf grossen Installationen relevant.
Hallo Rudolf,
ZitatVerstehe ich dich richtig: die Laufzeit eines Aufrufs verringert sich von 200ms auf 25 nur dadurch, dass man es seltener Aufruft?
Das sagt mir die Messung mit apptime unter den genannten Vorraussetzungen.
ZitatremoveFromNtfyHash()
??? Habe ich ein neues Problem aufgetan?
Was kann ich tun, um das weiter auzuklären?
Gruß, Ansgar.
Zitat??? Habe ich ein neues Problem aufgetan?
Nur etwas, was bisher auch existierte, als Problem definiert. :)
Hallo Rudolf,
ok, verstehe.
Die Weboberfläche ist auch leider der größte Störenfried, was Laufzeiten angeht. Indirekt also sich selber. ;)
Woher kamen denn die 60s? Schließt der Browser seine Verbindung teilweise schon früher? Unnötig früh FHEM seitig schließen bliebe ja in meinem Sinne weiterhin kontraproduktiv.
Danke für's Übernehmen der Optimierung.
Gruß, Ansgar.
Manche Browser lassen die Verbindungen laenger offen, und auf diese muss man auch aufpassen (==select).
Und dann gibt es den Fall, wo der Browser vom Netz geht, und FHEM das erst nach 2 Stunden mitkriegt (tcpkeepalive)
Ich habe FHEMWEB+TcpServerUtils jetzt beigebracht, removeFromNotifyHash nur fuer die inform Verbindungen aufzurufen.
Bin gespannt, was das in deinem Fall bewirkt.
Hallo Rudolf,
sieht erst mal gut aus, danke!
Auch im 60s Intervall im Mittel 16ms und max. knapp 30ms.
Gibt es für den Gegenspieler von removeFromNtfyHash auch noch entsprechendes Optimierungspotential?
Gruß, Ansgar.
Weiss nicht genau, was Du mit Gegenspieler meinst.
Klar koennte man removeFromNtfyHash weiter optimieren, aber mir ist der Aufwand, eine zweite Liste zu pflegen, zu hoch.
Z.Zt. habe ich vor TcpClose (nach und nach / je nach Beschwerde) mit dem dritten Parameter aufzurufen.
Wenn Du eine einfache Alternative hast...
Hallo Rudolf,
ZitatWeiss nicht genau, was Du mit Gegenspieler meinst.
ich meinte, ob createNtfyHash auch unnötig oft aufgerufen wird. ;)
Das Laden einer Seite schlägt noch deutlich heftiger zu Buche (ich nutze f18).
Und die praktische Ergänzung der Anleitungstexte bei set, get und Attributen ist leider auch zeitintesiv für meinen Pi, wie mir aufgefallen ist.
Gruß, Ansgar.