forum.opsi.org

Hallo,

aus irgendeinem Grund ist das Backend (ich bezeichne damit global alles, was "hinter" dem config editor resp. /usr/bin/opsi-admin ablaeuft) ist schleppend langsam. Ein simples `opsi-admin -d method getLocalBootProductStates_hash` ueber gerade mal 123 Clients braucht ueber 20 Sekunden, ein Neuladen des "Product Configuration" Tabs im config editor 15 Sekunden und das Wechseln vom Tab "Clients" zum Tab "Product configuration" nachdem man einen anderen Rechner ausgewaehlt hat 6-7 Sekunden. Das ist fuer fluessiges Arbeiten zu langsam. So sehr OPSI aus meiner taeglichen Arbeit nicht mehr wegzudenken ist, so sehr bremst einen diese Langsamkeit permanent. Wenn sich da etwas optimieren liesse, waere das ein grosser Gewinn fuer das interaktive Arbeiten insbesondere mit dem config editor.

Liebe Gruesse
frank

Hallo embl-structures,

wie schnell das Backend antwortet, hängt mit vielen Faktoren zusammen. Da spielen die verwendeten Backends (bspw. File oder MySQL) und die Geschwindigkeit der dahinter liegenden Komponenten eine Rolle. Dann gibt es eventuell ein Netzwerk, über das die Daten versendet werden müssen. Es kann auch einen Unterschied machen, ob OPSI rein virtualisiert oder auf echter Hardware eingesetzt wird.
Es bieten sich viele Schräubchen an, an denen man unabhängig von OPSI drehen kann, um eine bessere Performance zu erlangen.

Von OPSI-Seite kann man auf das (kostenpflichtige) MySQL-Backend umstellen, was sich IMHO gerade bei größeren Umgebungen lohnt. Eventuell hilft auch schon ein opsi-setup --cleanup-backend, falls viele Datenleichen im System liegen.

Und natürlich versuchen wir auch den OPSI-Code selbst peformant zu halten und zu verbessern. Das sind nicht nur allgemeine Änderungen im Backend, sondern auch ganz speziell an den Werkzeugen, bspw. dem Configed.
Ich persönliche freue mich, dass mit der neuen Version endlich keine uralten Python-Versionen mehr unterstützt werden müssen, da das doch die eine oder andere Möglichkeit schafft.

Auch, wenn wir kein Patentrezept zur Beschleunigung haben, hoffe ich doch, dass die Antwort ein paar Ideen zu Verbesserungsmöglichkeiten bringt.
Bei vorhandenem Support-Vertrag beraten wir gerne und können konkrete Hinweise liefern, wie Engpässen entgegen gewirkt werden kann.


Mit freundlichen Grüßen

Niko Wenselowski

n.wenselowski hat geschrieben:wie schnell das Backend antwortet, hängt mit vielen Faktoren zusammen. Da spielen die verwendeten Backends (bspw. File oder MySQL) und die Geschwindigkeit der dahinter liegenden Komponenten eine Rolle. Dann gibt es eventuell ein Netzwerk, über das die Daten versendet werden müssen. Es kann auch einen Unterschied machen, ob OPSI rein virtualisiert oder auf echter Hardware eingesetzt wird.

Die Hardware ist zugegebenermassen nicht gerade berauschend, aber am Netz liegt es mit Sicherheit nicht.

n.wenselowski hat geschrieben:Es bieten sich viele Schräubchen an, an denen man unabhängig von OPSI drehen kann, um eine bessere Performance zu erlangen.

Hat leider nicht geholfen, aber trotzdem Danke fuer den Tipp

n.wenselowski hat geschrieben:Und natürlich versuchen wir auch den OPSI-Code selbst peformant zu halten und zu verbessern. Das sind nicht nur allgemeine Änderungen im Backend, sondern auch ganz speziell an den Werkzeugen, bspw. dem Configed.

Nun. Wenn ich alle Informationen "von Hand" aus den Files lese (File Backend), bin ich 1-2(-3) Groessenordungen schneller als mit den jeweiligen opsi-admin-Subkommandos. Deshalb denke ich schon, dass die fehlende Geschwindigkeit zu einem grossen Teil direkt OPSI geschuldet ist. Natuerlich ist mir klar, dass opsi-admin vermutlich noch Konsistenzuberpruefungen durchfuehrt und Vieles andere, aber der Geschwindigkeitsunterschied ist zumindest in meinen Anwendungsfaellen dramatisch. Wenn gewuenscht, kann ich gerne ein Beispiel zusammenstellen..

Gruss
frank

Hallo frank,

embl-structures hat geschrieben:Wenn gewuenscht, kann ich gerne ein Beispiel zusammenstellen..

Das ist die beste Variante, da wir so ordentlich vergleichbare Ergebnisse bekommen können!
Dabei wär es natürlich am schönsten, wenn wir die gleichen Backend-Daten zur Verfügung hätten, um einen ordentlichen Vergleich zu haben. Falls das nicht geht, könnte man anhand deiner Kennzahlen versuchen eine ähnliche Umgebung aufzubauen.


Gruß

Niko

Hallo embl,

das Problem ist uns bekannt. Das liegt aber mehr an der Ausgabe. Da die Ausgabe noch mal geparsed und aufgehübscht wird: Einrückungen etc.

Diese Methode war enorm langsam implementiert. Dieser Fix hat es dank deinem Hinweis noch mal in letzter Minute in dieses Release geschafft. Give the testing release a try, kann ich da nur sagen. Je mehr Leute Testen und Feedback zurückliefern, desto eher können diese Fixes auch in den Stable-Bereich.

Grüße
e. ueluekmen