Transparanz abschalten hilft

Tja, so einfach ist das. Im Standard von Kubuntu sind ziemlich viele schöne Schalter im KDE Umfeld eingeschalten. Unter anderem ist die Transparenz von den einzelnen Seiten aktiviert.
Und da der Asus Eee 900 nun wirklich nicht der absolute Rechenleistungskönig ist, ist dieser Schalter einfach nicht sinnvoll.
Nachdem ich die Transparenz ausgeschalten habe, verhielt sich die Maschine (fast) so wie unter Gentoo.

Was mach ich als nächstes?

Damit ich die Performanceunterschiede zwischen Gentoo und Ubuntu nun mal ausprobieren kann, werde ich das Gentoo System fertig konfigurieren. Dann werde ich dort mal die Transparenz einschalten und schauen ob die Maschine auch unter Gentoo zusammenbricht.

Wie Ute schon geschrieben hat, sind wir seit ca. 1,5 Wochen sehr massiv daran unsere Baustelle fertig zu stellen. Ich werde daher nur sehr spärlich zum Bloggen und zum Performance Testen kommen. Aber im Moment sind ja sowieso Sommerferien und da muss ich nicht in gewohnter Manier bloggen gelle?

Ich wünsche euch schöne, warme Sommertage und performante Rechner!

Ähnliche Beiträge

Ähnliche Beiträge

Fazit

In ein paar Jahren werde ich ein neues Windows bekommen und wieder jammern dass früher alles besser war. Folglicherweise ist die einzige Konstante, die ich bisher erkennen kann, die Startzeit der Computer und der Jammeraufwand der Menschen.
Ist doch schön wenn man Traditionen aufrecht erhalten kann gelle?

Ähnliche Beiträge

Ähnliche Beiträge

Ähnliche Beiträge

Vorteile dieser Lösung

Wir müssen nur an einer Stelle im System die Messungen durchführen.
Das System ist einfach zu erstellen und benötigt nicht viele Hirnverenkungen.
Wir können die Daten einfach zusammen sammeln und haben einen Ort um sie zu speichern und anschliessend darzustellen.

Nachteile dieser Lösung

Unangenehm an dieser Lösung ist, dass wir komplexe Abläufe auf dem Client nicht mitbekommen.
In einer AJAX Anwendung kann es vorkommen, dass der Client sämtliche Validierungsprüfungen lokal durchführt und nur alle paar Minuten mal mit dem Server kommuniziert. Wir bekommen also keine sinnvollen Informationen des Clients auf dem Server gesammelt.

Was machen wir jetzt?

Wir denken darüber nach, ob wir Messpunkte in die Architektur einfügen wollen. Wenn wir der Meinung sind, dass dies eine gute Investition ist, werden wir die entsprechenden technischen Anwendungsfälle herunterschreiben.

Aufgabe

Denke mal ein bisschen über die Vor- und Nachteile nach. Willst du eine Zwischenschicht einführen, oder nur Messungen auf dem Server durchführen?
Ist der Aufwand zum Erstellen gerechtfertigt oder sollen wir es lassen und drauf ankommen lassen?

Ähnliche Beiträge

Was für Ein- und Ausschaltmöglichkeiten haben wir?

Auch hier gibt es wieder viele Möglichkeiten wie wir vorgehen können.

Hardcodierte Lösung

Wir könnten zum Beispiel eine Datei auf dem Server hinterlegen und in dieser Datei einen Wert eintragen. Wenn der Wert z.B. check_performance=true gesetzt wurde, liefern wir den Performance-Messungscode mit aus. Wenn nicht, werden wir einen leeren Performance-Messcode, also ein Stück Software dass nur das Interface abbildet aber keinerlei weiteren Code beinhaltet, ausliefern.
Damit bleibt im Normalfall unser AJAX Client schön schlank und rank. Wenn wir dann mal messen müssen, laden wir die dafür notwendigen Codesegmente zum Client.
Cool oder?
Wir können auch den Code immer mit ausliefern. Das hat den Vorteil, dass wir keine zwei Codesegmente (die auscodierten und die leeren) testen müssen.
Der Nachteil dieser Lösung ist, dass irgendjemand die Datei entsprechend anpassen muss. Und da wir das Newssystem irgendwo im Internet betreiben, kann es sein das wir keinen Zugriff auf die Datei haben.

Oberfläche zum Ein- und Ausschalten

Schöner ist vielleicht, wenn wir eine Oberfläche zusammenstellen mit der der Systemadministrator das Performancemessen ein- und ausschalten kann. So können wir ganz gezielt die Messung ansetzen.
Der Nachteil hierbei ist, dass wir für den Systemadministrator eine entsprechende Oberfläche bereithalten müssen. Das ist wiederum mit Aufwand verbunden. Wir müssen die Oberfläche erstellen und später den Code warten.
Tja, irgendwie gibt es wohl keine Ideallösung gelle?

Ähnliche Beiträge

Gibt es denn eine bessere Lösung?

zum Einen möchte ich sagen, dass die zuvor vorgestellte Lösung nicht 100% schlecht ist. Sie ist halt nicht schön… Zum Anderen gibt es immer andere Möglichkeiten.
Wir können zum Beispiel an bestimmten Punkten in unserer Architektur Messpunkte einbauen die uns erlauben, ohne den fachlichen Code zu verhunzen, Messungen durchzuführen.

Zwischenschicht zur Performancemessung einführen

Unsere AJAX Anwendung hat mindestens zwischen dem Client und dem Server eine Kommunikationsschicht. Hier ist ein recht schöner Platz um Daten abzufangen und für Zeitmessungen aufzubereiten. Wir senden ja sowieso Daten zum Server und dann packen wir halt noch ein paar Informationen hinzu.
Der Nachteil dieser Lösung ist, dass wir in AJAX Anwendungen manchmal sehr lange Zeit nicht mit dem Server kommunizieren. Wenn wir alle Tests für die Eingabevalidierung weitgehenst autonom auf dem Client realisieren, werden wir wenig Informationen über die Performance an den Server senden können.

Zwischenschicht mit Messaging System zwischen den Client Komponenten

Weiterhin können wir eine Kommunikationsschicht zwischen den einzelnen Bereichen der AJAX Client Applikation erstellen. Wenn unsere Objekte miteinander reden, können wir das Gespräch in der Kommunikationsschicht mithören und die notwendigen Messpunkte einführen.
Wir können die Performance und weitere Informationen, wie Fehleingaben des Benutzers, Bewegunbsinformationen usw. mitloggen. Wir können unsere einzelnen Komponenten schön lose miteinander koppeln und so wenig vermischten Code erzeugen.
Wenn du mich fragst, dann würde ich so eine Messaging Zwischenschicht sehr gut finden.

Ähnliche Beiträge

Was könnten wir für die Performance Messung machen?

Wenn wir ein klein wenig clever sind, werden wir unser System gleich von Anfang so gestalten, dass wir hinterher Performance Messungen ohne großen Aufwand durchführen können.
Wenn unsere Systemarchitektur es uns ermöglicht, hier- und da Messpunkte einzusetzen und die Informationen zu sammeln, dann können wir ohne Hektik die Messungen durchführen und “das Langsam” mit Zahlen belegen.

Erster Versuch eine Performance Messung einbauen

Eine Möglichkeit ist, an kritischen Punkten die verbrauchte Zeit zu messen und an einer sinnvollen Stelle zwischenzuspeichern.
Wir können also in all unsere Funktionen an den Punkten, an denen wir glauben dass etwas interessantes passiert, die Zeiten messen und einem Datensammler übergeben.

Ist das ideal?

Naja, ideal ist ja bekanntermaßen gar nichts. Aber wir haben hier noch ein paar Problemchen die unser Design weniger Elegant erscheinen lassen.
So wie ich unser System bisher beschrieben habe, werden wir ziemlich viel Code in den einzelnen Funktionen reinfummeln müssen. Wir müssen bevor ein Performance Problem auftritt schon wissen wo es auftreten wird.
Ich weiss zwar nicht wie gut du im Umgang mit Wahrsager-Glaskugeln bist. Mir ist vor kurzem meine Glaskugel heruntergefallen und zersprungen. Das passierte, als ich in die Glaskugel geschaut habe und die Zukunft betrachtete. Ich sah, dass ich erschrecke und die Glaskugel herunterfallen wird. Nun, dann bin ich erschrocken und die Glaskugel ist heruntergefallen
Wir kennen die Zukunft nicht und werden daher vermutlich nicht an allen vernünftigen Punkten Messpunkte einführen.
Wir werden zu wenig- oder zu viele Messpunkte definieren. Und mit dem Einbau von Messpunkten mischen wir in unsere fachliche Logik noch irgend welche technische Logik ein. Der Code wird unleserlich, nicht mehr wartbar und garantiert langsam da wir ja hunderte von Messungen vornehmen werden gelle?
Mist, das war es wohl noch nicht.

Ähnliche Beiträge