forum.opsi.org

Hallo zusammen!

Mir ist gerade wieder aufgefallen, dass die Spazialanfrage im configed (Menü --> Auswahl --> Spezial: Clients mit nicht aktuellem Produkt) im Gegensatz zu einer freien Anfrage um Einiges schneller ist. Die langsamen, freien Abfragen habe ich mir immer mit MySql in Verbindung mit den Java Frontend erklärt, jedoch zeigt mir die Spezialabfrage, dass es auch viel schneller gehen kann. Jetzt stellt sich mir natürlich die Frage, ob ich meine freien Anfragen mit zu wenigen Einschränkungen ausführe, oder ob hinter der Spezialanfrage etwas anderes/zusätzliches als eine Datenbankabfrage steht.

Hat sich damit evtl schon jemand beschäftigt und kann mir auf die Sprünge helfen?


Gruß
Kathrin

Hallo,

der beobachtete Unterschied der Antwortzeiten beruht wahrscheinlich darauf, dass bei der Suche zunächst alle angesprochenen Tabellen komplett über den opsiconfd geholt werden, um die Auswahl dann lokal im configed nach den frei definierten Kriterien durchführen zu können, während bei der "Spezial"-Funktion im Wesentlichen die Datenbank selbst schon die Auswahl durchführt. Wenn die Daten einmal geladen sind, sollte eine erneute Suche (auch mit veränderten Kriterien) praktisch so schnell gehen wie, wenn die Datenbank gefragt und das Ergebnis über den opsiconfd an den configed übermittelt wird.

Wir sind aber für alle Hinweise auf Probleme dankbar, die neue, umfangreiche Suchfunktion ist relativ frisch neuimplementiert und nicht frei von Macken

Grüße

Rupert

Hallo,

danke für die Antwort. Ich schildere mal das Verhalten wie es hier abläuft....
Es scheint, als dass jedes Mal alle angesprochenen Tabellen über den opsiconfd geholt werden, weil es im configed wirklich immer lange dauert bei einer freien Anfrage.

Zu meiner Vorgehensweise:
configed --> Freie Anfrage

Auswahl z.B.:
opsi-Produkt/ID --> 7-Zip (and)
opsi-Produkt/Stand --> installed
Durchführen

Ansonsten treffe ich keine Auswahl. Wenn ich jetzt auf Durchführen klicke dauerte es ca 27 Sekunden (ich habe nur im Kopf mitgezählt) bis mir die Clients angezeigt werden bzw. in der Clientübersicht ausgewählt sind, damit ich filtern könnte. Eine direkte Abfrage in der Datenbank mit wurde in weniger als einer Sekunde durchgeführt.

Wenn ich im noch geöffneten Freie Anfrage Fenster jetzt nochmal genau die gleiche Abfrage ausführe (mit den eingestellten Kriterien von vorher) dauerte es ca 23 Sekunden.

Zu unserer Umgebung: ~750 Clients, 155 installierte Produkte:

ii opsi-atftpd 0.7.dfsg-2.1 advanced TFTP server - opsi version with pcre, fifo and max-blksize patches
ii opsi-configed 4.0.3.2.1-1 OPSI config editor
ii opsi-depotserver 4.0.3.1-1 opsi depotserver configuration package
ii opsi-linux-bootimage 20130207-1 opsi linux bootimage
ii opsi-utils 4.0.3.1-1 opsi utils
ii opsiconfd 4.0.3.1-1 opsi configuration service
ii opsipxeconfd 4.0.3.1-1 opsi pxe configuration daemon
ii python-opsi 4.0.3.1-1 opsi python library

Falls noch weitere Infos/Log benötigt werden kann ich Sie ihnen gerne zukommen lassen.

Gruß
Kathrin

Hallo,

was ich geschildert habe, war tatsächlich nur der gedachte Ablauf - in Wahrheit lädt der configed tatsächlich bei jedem Suchauftrag die Tabellen neu; und das ist ein Bug, den ich für die kommende Version direkt behoben habe.

Das zweite Problem sind die extrem langen Ladezeiten bei Tabellenabfragen über den opsiconfd. Hier arbeiten wir intensiv an einer signifikanten Performancesteigerung und planen, ein entsprechendes Community-Projekt, das für große Installationen wie Ihre relevant ist, aufzulegen.

Für eine spezifische Unterstützung für Ihre Situation können Sie auch gerne den Support nutzen, den Sie als uib-Kunde ja in Anspruch nehmen können.

Grüße
Rupert Röder

Hallo,

ich habe eine entsprechende Anfrage nochmal nachgestellt mit der experimentellen Version des configed und opsiconfd, die wir gerade testen.

Die "freie Anfrage" sucht nach allen Clients mit "7zip" auf "installed". Auf meiner "Stressumgebung" mit 3500 Clients und 250 Produkten ergeben sich folgende Werte:

- bisheriger configed: ca 80 Sekunden für Erstabfrage, 2 Sekunden für Wiederholung innerhalb der Suchmaske (daher gleiche Datengrundlage, Suchparameter können dabei variiert werden);

- experimenteller configed: ca 8 Sekunden für Erstabfrage, 2 Sekunden für Wiederholung

Der Unterschied kommt daher, dass das lokale Caching deutlich effektiviert wurde (das ist aber immer noch Luft )
Hauptsächlich der Datendownload verbraucht Zeit,


Grüße
Rupert Röder

Hallo,

vielen Dank fürs Testen und die Informationen. Dann werde ich mal geduldig auf die nächste Version warten Ich stelle mich gerne als Tester zur Verfügung

Gruß
Kathrin