Das freut mich. 
Hast Du Vergleichswerte zu den vorherigen 27 Sekunden?
Ja, praktisch sofort nach dem Einloggen, also ca. 1-2 Sekunden. Aber die nächsten Tage werden zeigen, ob es stabil bleibt.
Ich vermute mal, dass es mit steigender Anzahl an neu hinzukommenden IP-Adressen wieder langsamer werden wird.
Es wird sich bei den Neuzugängen sehr wahrscheinlich um öffentliche IPv6-Privacy-Extensions-Adressen handeln. Diese sind nur begrenzt gültig und werden daher von Deinen Clients häufig erneuert (standardmässig einmal pro Tag, je nach OS aber auch deutlich öfter).
Nach den bisherigen Beobachtungen würde ich vermuten, dass die hohe Zahl von Anfragen in Verbindung mit einer hohen Zahl von Client-IPs zu dem verlangsamten Seitenaufbau beiträgt.
Dazu würde auch passen, dass die Anzahl der DNS-Anfragen konstant bleibt, während der Seitenaufbau von Tag zu Tag etwas mehr Zeit braucht, eben weil täglich neuie IP-Adressen hinzukommen.
Das zugrundeliegende Clientverhalten wird Pi-hole nicht ändern können, zumal Privacy Extensions bei öffentlichen IPv6-Adressen durchaus sinnvoll sind.
Unabhängig von Deinem Anliegen wird die (oder eine) nächste Version von Pi-hole allerdings voraussichtlich eine neue Konfigurationsoption mitbringen, mit der sich die Menge der IP-Adressen auf eine Anzahl von Tagen einschränken lässt.
Ausserdem wird Pi-hole für die stündlich laufenden Rückwärtsanfragen (in Deiner Grafik wohl als Peak zur vollen Stunde zu erkennen) die Menge der dazu genutzten IP-Adressen ebenfalls einschränken.
In der Zwischenzeit kann Dir möglicherweise auch folgende, nicht ganz saubere Konfiguration helfen: Du kannst versuchen, Pi-holes link-lokale IPv6-Adresse (aus dem Bereich fe80::/10) in der FB einzutragen. Dadurch wären Deine Clients gezwungen, ebenfalls nur link-lokal anzufragen, d.h. es tauchen nur deren fe80:-Adressen in Pi-hole auf, für die im allgemeinen Privacy Extensions nicht aktiv sind.
In segmentierten Netzwerken wird dies allerdings nicht mehr sauber funktionieren: Geräte, die in unterschiedlichen VLANs liegen oder über zusätzliche Netzwerkgeräte wie z.B. einen weiteren Router, AP oder L3-Switch verbunden sind, können Pi-hole über die link-lokale IPv6-Adresse nicht erreichen.
The database has to be accessed and read, and the information loaded into RAM. The more data in the past 24 hours, the longer this takes.
Sollte das der Fall sein, dann bitte ich mithilfe der Developer Tools zu protokollieren, welche Komponente für den langsamen Aufbau verantwortlich ist. Vielleicht kommen wir so weiter.
Mal davon abgesehen,
da stellt sich mir die Frage was Du damit genau meinst:
- 27s bis überhaupt etwas kommt (vorher weiße Seite), oder
- 27s bis alle Elemente einzeln geladen wurden, oder
- 27s bis der Browser überhaupt irgendetwas macht, oder
- ... etwas ganz anderes
27 Sekunden bis die Hauptseite mit den Statistiken angezeigt wird und man im Menü irgendetwas anklicken kann.
Aktuell sieht es so aus:
3|32|thorstens-mini.fritz.box
6|26|ipad-og.fritz.box
10|21|lapthorg.fritz.box
9|17|axisnvr-o7ho53k.fritz.box
67|16|edimax-sma-3.fritz.box
11|16|amazon-98ed7739d.fritz.box
12|13|thorsten-air.fritz.box
14|10|ipad-eg.fritz.box
13|6|edimax-sma-1.fritz.box
86|5|qnap-ts-463u.fritz.box
Was passiert innerhalb dieser 27 Sekunden? Ist der Rechner beschäftigt und die Seite reagiert nicht (wird aber bereits angezeigt) oder ist dort eine weiße Seite (oder etwas anderes)?
Nach dem Einloggen ist die pihole Seite wie eingefroren.
Die Rechner (Mac) läuft ganz normal.
Aha, dann ist es wohl keine Problem von ihre Pi-hole but von ihre Browser. Passiert das mit allen Browser gleich? Vielleicht haben sie noch ein Mobiltelefon von dem sie testen können. Vielleicht auch Firefox/Chrome.
Es ist kein Problem vom Browser.
Diese Ladezeiten waren immer bei Safari unf Chrome identisch.
Doch, ich denke es ist ein Problem in die Browser. Bitte entschuldigen sie meine schlechte Deutsch, ansonsten geht es auch in Englisch oder Niederländisch
Ich meine damit dass ich denke das Problem findet im Browser statt. Es liegt schon an pi-hole, aber es ist nicht ein Problem mit der Pi-hole selbst sondern mit der Oberfläche, für die ihr Browser viel Rechenleistung braucht um sie anzuzeigen.
Die Screenshot wie von @DL6ER gefragt würde das zeigen wer wann die Daten anliefert. Das würde das Bild klarer machen. Man bekommt diese Fenster mit [F12].
Update:
Läuft immer noch alles perfekt und ohne Verzögerung.
3|34|thorstens-mini.fritz.box
6|33|ipad-og.fritz.box
10|28|lapthorg.fritz.box
9|21|axisnvr-o7ho53k.fritz.box
11|20|amazon-98ed7739d.fritz.box
67|18|edimax-sma-3.fritz.box
12|15|thorsten-air.fritz.box
88|12|thorstens-mini.fritz.box
14|12|ipad-eg.fritz.box
55|6|galaxy-s10-5g.fritz.box
Hallo, ich hänge mich mal dran.
Seit der Umstellung auf Dual-Stack habe ich auch das Problem der langen Ladezeiten.
Anzahl der Clients geht jetzt auf 100.
4|165|pc-andreas-lan.pilan
26|123|pc-felix-lan.pilan
34|116|pc-heike-wlan.pilan
25|63|pc-nina-wlan.pilan
21|54|mobile-lotte-i6plus.pilan
28|51|pc-felix-wlan.pilan
2|46|mobile-heike-g5.pilan
24|40|mobile-nina-i8.pilan
23|31|mobile-felix-g6.pilan
1|29|mobile-andreas-g6.pilan
Ansonsten läuft alles bestens.
Gruß
Andreas
Hmm, okay, das Dashboard hat also Probleme bei einer hohen Anzahl an Clients die Graphen zu zeichnen. Bei solch einer hohen Anzahl an Clients macht das vielleicht durchaus Sinn.
Es gibt zwei (zukünftige) Lösungsansätze, die mir spontan in den Sinn kommen:
- Man erstellt
alias-clientsfür alle Geräte. Darunter werden dann die Clients auch mit mehreren dutzend Adressen zu einem Gerät zusammengefasst. Damit wäre das Problem gelöst. - Als "fallback" könnten wir auch noch eine Vorsichtsmaßnahme vorsehen, dass in diesem Graphen maximal, sagen wir, 25 Clients geladen werden. Mehr ließen sich wohl eh nicht unterscheiden. Damit wäre das Problem zumindest für diejenigen, die Schritt 1 nicht gemacht haben, abgemildert bis sogar verhindert.
Was sagt Ihr?
Hallo,
es ist nicht nur eine Anzeige Problem sondern man kann in der Wartezeit auch nichts links am Menue auswählen.
Kann man nicht sonst die grafische Darstellung vom Menue trennen?
Kann man nicht dieses Script vom @Bucking_Horn automatisiert laufen lassen?
Moin,
da stimme ich zu.
Das was mich etwas stört ist, dass die gesammte Seite während des Grafikaufbaus blockiert ist.
Eine Trennung fände ich an dieser Stelle sinnvoll.
Die vorgeschlagenen Lösungen klingen gut. Ich brauche die Graphen auch eher für einen groben Überblick, alle Details an dieser Stelle zu zeigen ist m.E. nicht nötig.
Ist es denn überhaupt notwendig jedesmal den kompletten Graphen neu zu rechnen?
Das ist leider nicht machbar. Die Segemente sind bereits in der Seite getrennt, wenn ein Teil einer Seite jedoch beschäftigt ist, reagiert die gesamte restliche Seite nicht mehr. Ich habe das gestern testweise mit einer Dummy-Webseite ausprobiert (völlig unabhängig von Pi-hole) und dort das gleiche festgestellt: Wenn eine Seite mehrere Elemente hat und eins der Elemente verrückt spielt (in meinem Demo-Fall war das eine Endlosschleife auf einem Feld), dann hängt die gesamte Seite in Firefox und Chrome. Das scheint einfach eine Browserlimiertung zu sein.
Ich denke mit dem Mittelweg des beschränkens der Datenmenge werden wir das Problem in den Griff bekommen.
Da wird eigentlich nichts gerechnet, der Browser bekommt die Daten fertig angeliefert und muss sie lediglich noch in ein Format bringen, welches das Zeichenplugin unterstützt. Hier scheitert es dann an der bescheidenen Performance des Zeichenplugins für sehr große Datensätze.
Bitte versucht einmal
pihole checkout ftl fix/MASTER_getClientsOverTime_only_active
Diese Version von FTL übermittelt keine Daten für Clients (im Sinne von IP Adressen), die gerade inaktiv sind. Das könnte in Eurer Situation hilfreich sein und ist deutlich schneller als eine Aussortierung nach den 25 aktivsten.
Sollte dies funktionieren, wird diese neue Methode durch folgenden Pull Request in den Code integriert:
1 Like
root@DietPi:~# pihole checkout ftl "fix/MASTER_getClientsOverTime_only_active"
Please note that changing branches severely alters your Pi-hole subsystems
Features that work on the master branch, may not on a development branch
This feature is NOT supported unless a Pi-hole developer explicitly asks!
Have you read and understood this? [y/N] y
[✗] Requested branch "fix/MASTER_getClientsOverTime_only_active" is not available
Wird als available angezeigt, aber er will nicht...
Lass mal die Anführungszeichen weg....
pihole checkout ftl fix/MASTER_getClientsOverTime_only_active