Flash – Redraw/Reload-Verhalten von Browsern

Posted on by

So schöne Dinge man mit Flash machen kann: Beim Einsatz ist immer wieder Vorsicht geboten!

Wir haben z.T. sehr schlechte Erfahrungen mit dem Verhalten verschiedener Browser gemacht, wenn es darum geht, zwischen Seiten mit praktisch identischem Layout zu wechseln. Da in einem solchen Szenario viele Objekte im Browser gecached werden können, hofft man bei solchen Seiten auf einen sanften Übergang – also ohne viel Flackern beim Rendern der neuen Seite. Objekte die beim Seitenwechsel statisch bleiben, sollen auch im Browser statisch erscheinen.

Wichtig wird dies dann, wenn man auf einer Firmenseite viele einzelne Seiten hat, die im Hintergrund und in anderen Bereichen praktisch gleich aussehen. Hier möchte man als Betrachter einen ruhigen Wechsel ohne störende Reloads und ohne Neuzeichnen des Hintergrunds bzw. der statisch bleibenden Seitenelemente erleben. Nur veränderte Inhaltsbereiche sollen sich bei Rendern visuell sichtbar ändern.

Gerade dann, wenn die HTML-Seiten Flash-Objekte beinhalten, wird diese Erwartungshaltung an eine flackerfreies Browserverhalten aber oft genug nicht erfüllt. Im Gegenteil beeinträchtigt z.T. deutliches und wirklich störendes Flackern den Seitenaufbau. Zumal man hierfür als Betrachter keinen Grund erkennen kann und dies von Seiten ohne Flash-Inhalt auch nicht gewohnt ist.

Wir haben das “Redraw”-Verhalten von verschiedenen Browsern unter Linux und Windows ein wenig getestet. Hier unser Ergebnis, das wir auch an die Entwickler von Opera und Firefox weitergeleitet haben.

Unter Linux muss man feststellen, dass die von uns verwendeten Browser “Konqueror Firefox und Opera” generell den Bereich des Flashobjektes beim Wechsel zwischen nahezu gleichen Seiten neu zeichnen.

U.U. werden aber auch andere Objekte neu gerendert bzw. nachgeladen – gerade Firefox spielt hierbei eine unrühmliche Rolle! Dieser Browser zeichnet generell Layer (DIVs und ihren Inhalt) sowie Images neu, sobald die Seiten auch nur ein einziges (identisches) Flash-Objekt beinhaltet. Auch wenn sämtliche Elemente der Seiten gecached wurden. man muß allerdings festhalten: Das geschieht ausschließlich beim Wechsel zwischen Seiten, die Flashobjekte beinhalten. Hier kommt es – selbst bei 99% identischem Layout – zu deutlichen sichtbaren Beeinträchtigungen beim Bildaufbau. Interessanterweise zeigt die Windows-Version von Firefox dieses Verhalten nicht !

Dass es unter Linux auch viel besser geht, zeigen dagegen Konqueror und Opera. Beide Browser zeichnen nur den Flashbereich neu, wenn der Inhalt der Seiten zwischen denen gewechselt wird, praktisch identisch ist.

Überraschenderweise bietet Opera unter Windows das schlechteste Verhalten an. Hier wird alles neu gezeichnet, sogar der Hintergrund (bzw. die Hintergrundsfarbe) einer Seite. Resultat ist ein massives Flackern beim Seitenaufbau, da immer auch die Standardfarbe des Hintergrunds – nämlich Weiß – kurz sichtbar wird. Damit wird ein Wechsel zwischen Seiten mit einer Mischung aus HTML- und Flash-Content zu einem Erlebnis der besonderen, wenn auch negativen Art.

Das beste Verhalten bei unseren Tests zeigte der IE 7 unter MS Windows – allerdings auch nur, wenn die Seiten keinen komplizierten Layeraufbau mit vertikaler Schichtung aufwiesen. Mit vertikal geschichteten Layern kann der IE unserer Erfahrung nach beim Seitenwechsel insgesamt nur schlecht umgehen – im Gegensatz zu Firefox (solange kein Flash im Spiel ist).

Entfernt man die Flashinhalte aus Testseiten, so reduzieren sich die Flackereffekte, die mit dem Rendervorgang beim Seitenwechsel auftraten, sehr deutlich. Daraus ist zu schließen, dass das Zusammenspiel zwischen Flash-Plugin und der jeweiligen Browser-Engine in den betrachteten Browser-Varianten unterschiedlich gelöst wurde.

Deutliches Verbesserungspotential besteht unserer Meinung nach beim Firefox (Linux) und Opera (Windows).

Mehr und detailliertere Informationen sowie ein Testszenario findet man im Anhang (s.
nachfolgender Link).

Test zum Redraw Verhalten von Browsern beim Wechsel zwischen Seiten mit Flash-Content

Testdateien bitte per Mail vom Verfasse anfordern!

OX5 – Login Problem mit Konqueror – Nachtrag II

Posted on by

Es ist nun schon einige Zeit ins Land gegangen, seit das zuletzt beschriebene Login-Problem unter dem Browser Konqueror aufgetreten ist. Es gab auch einen erfreulich regen Austausch mit einem der KDE-Entwickler.

Leider haben die bisherigen Korrekturen zum korrekten Parsing von HTTP-Headern das Problem nicht behoben. Im Moment steht nur soviel fest:

1) Meine eigenen Tests in unserem Firmennetzwerk (mittels einiger PHP-Programme und einer Paketanalyse mit Wireshark) zur Interpretation von HTTP Redirect-Anforderungen (Refresh, Location – Direktiven) durch den Browser Konqueror sind alle positiv verlaufen. Daran scheint es also nicht zu liegen.
2) Die vom OX5-Server im Redirect angeforderten Cookies werden korrekt gesetzt. Der xhtml-Inhalt der HTTP – Refresh-Anforderung an den Browser wird korrekt dargestellt – der Refresh wird jedoch nicht mehr durchgeführt. Es wird kein entsprechendes HTTP GET – Paket an den Server zurückgesandt.
3) Das Problem tritt definitiv erst nach der ab Version 3.5.7-64.1 des kdebase3- bzw. des kdelibs3-Paketes auf. Nachweislich nicht nur auf meiner Installation. Es hat auch nichts mit der bei uns eingesetzten 64Bit Architektur zu tun.
4) Es ist unklar, wie Konqueror mit “chunked” Inhalt der HTTP-Pakete umgeht (“Transfer-Encoding: chunked”). Interessanterweise versendet der OX5 Server seine Mitteilungen an den Browser auf diese Weise. Mir drängt sich ein wenig der Verdacht auf, dass es evtl. ein Konqueror-Problem geben könnte, wenn die vorgegebenen “chunks” alle in einem einzigen IP-Paket Platz finden. Aber das müssen die KDE-Leute herausfinden.

Zusatzanmerkung:
Angesichts der seit 11. August geltenden Rechtslage (Strafrecht §202c) möchte ich betonen, dass eine gründliche Analyse des Problems eigentlich nur unter Beobachtung des Paketaustausches zwischen Client und Server möglich ist. Ich habe mir deshalb wegen der neuen Gesetzgebung als Inhaber der Firma selbst und höchst offiziell die Erlaubnis erteilt, in meiner zweiten Rolle als Administrator die Paketverfolgung in unserem firmeneigenen Netzwerk temporär und auf 2 Rechner begrenzt durchzuführen und danach alle eingesetzten Hilfsmittel wieder von den Systemen zu entfernen.

Wer das für schwachsinnig hält, hat zwar irgendwie Recht, möge sich aber bitte mal mit der neuen Rechtslage auseinandersetzen – danach stellt womöglich allein der Besitz von solchen Analyse-Tools ein Gesetzesvergehen dar (siehe etwa entsprechende Artikel in den letzten Ausgaben des Linux-Magazins oder aber aktuelle Artikel im PC Magazin) .

Diesem Wahnsinn haben übrigens alle Parteien außer der PDS im Bundestag zugestimmt. Wer also gegen die völlig diffuse Ausformulierung des §202c noch nicht beim Bundestagsabgeordneten seines Vertrauens protestiert hat, sollte dies nachholen. Hier ist insgesamt eine sehr ungute Entwicklung im Gang, die man als IT-Fachfrau oder -mann und als Demokrat nur mit allergrößtem Misstrauen beobachten kann. Hierzu schreibe ich aber bei Gelegenheit einen separaten Beitrag.

VMware und Athlon Dual Core Prozessor – Tipp 1

Posted on by

VMware und Athlon Dual Core Prozessoren – Teil 1: Nutze nur einen (virtuellen) Prozessor !

Ich gebe hier meine Erfahrungen mit der Installation von VMware (Workstation Versionen 5 und 6) auf einem Athlon X2 4800+ Prozessor unter Linux (Opensuse) wieder. Linux ist dabei also das sog. VMware “Host”-System”. Als “Gast-System” kam Windows XP SP2 zum Einsatz.

Wenn man eine virtuelle Maschine unter VMware aufsetzt, hat man auf einem Host-System mit einem Dual Core Prozessor die Möglichkeit, dem Gast-System 1 oder 2 (virtuelle) Prozessoren zuzuordnen. Nach etlichen Versuchen mit der Auswahl von 2 (virtuellen) Prozessoren bleibt festzuhalten:

Finger weg von einem Setup mit 2 virtuellen Prozessoren!

Hierfür gibt es vor allem zwei Gründe:

1. Unnötig verschlechterte Perfomance des Gesamtsystems durch Verwaltungsoverhead
Vor allem die Performance des Hostsystems leidet bei einem solchen Setup. Wie man diversen Beiträgen im Workstation-Forum von VMware entnehmen kann, wird das System mit den Verwaltungsaufgaben zur

  • Verteilung der Gastsystemlast zwischen den virtuellen Prozessoren und
  • der resultierenden Verteilung der Host-System-Last auf die 2 realen Prozessorkerne

insgesamt über Gebühr belastet. (Das wirkt sich natürlich dann auch auf die Performance des Gastsystem aus.)

In meinem Fall drängte sich oftmals der Eindruck auf, dass das System deutlich mehr mit der Auflösung der Anforderungen aus der Lastverteilung – also mit sich selbst – beschäftigt war als mit dem Abarbeiten von Applikationsanforderungen im Gast- oder Hostsystem.

Ich habe z.T. eine durchschnittliche Auslastung von 50% im Host-System gesehen, die durch Systemprozesse verursacht wurde, während sowohl im Windows-Gastsystem als auch unter Linux die Auslastung durch Userprozesse kleiner als 10% war. Die Aufgabe der Abstimmung von Lastverteilungsanforderungen zwischen Gastsystem und Hostsystem ist nach meinem Eindruck (noch) nicht optimal gelöst. Manchmal konnte ich ein fast zyklisches Hin- und Herschaufeln der Last zwischen beiden Prozessorkernen beobachten. Es war so, als ob eine Entscheidung des Gastsystems zur Lastumverteilung eine gegenteilige Reaktion des Hostsystems und diese dann wiederum die umgekehrte Reaktion im Gastsystem hervorrief. Ein solche Interpretation würde die beobachtete permanente (und völlig überflüssige) zyklische Lastumverteilung zumindest im Ansatz erklären.

VMware selbst rät übrigens wegen der Gefahr einer verschlechterten Gesamtperformance von einem Setup des Gastsystems mit 2 (virtuellen) Prozessoren ab. Der übliche Kommentar ist, dass dies nur auf größeren als Quadcore-Systemen sinnvoll sei.

Verschärft wird das ganze ggf. auch noch durch Bedingungen, wie Sie nachfolgend beschrieben werden.

2. Taktung und Schwierigkeiten mit der Synchronisation der Prozessorcores
Nach einigen Recherchen im Internet kommt man zu dem Schluss, dass bestimmte frühe Baureihen des AMD X2 Prozessors das Manko aufweisen, dass die Cores unabhängig voneinander getaktet wurden. Jeder Core hat(te) sozusagen seinen eigenen Zeitgeber. Applikationen, die die CPU-Zyklen der Cores abfragen, haben damit erhebliche Schwierigkeiten, wenn das Betriebssystem zwischenzeitlich die Last zwischen den Cores umverteilt: die Applikation erhält dann ggf. eine andere Antwort zum Zyklus, als sie erhalten hätte, wenn die Applikation auf dem ursprünglichen Core verblieben wäre.

Bei den ersten 5er-Versionen der Workstation hatte ich den Eindruck, dass dies der Grund für Instabilitäten im Gastsystem war, wenn man VMware linuxseitig nicht genau einem – und zwar dauerhaft ein und demselben – Prozessorkern zuordnete. Die Einschränkung, VMware dauerhaft einem Prozessorkern zuzuweisen, gilt heute nach meiner Erfahrung jedoch nicht mehr.

Fazit: Man sollte dem (virtuellen) Gastsystem im Setup
genau eine (virtuelle) CPU zuweisen.

In einem weiteren Beitrag werde ich darstellen, wie man die Frequenz der CPU ermittelt und im VMware-Setup der virtuellen Maschine als feste Größe verankert. Damit lassen sich Probleme umgehen, die die vmware-seitige eigenständige Frequenzbestimmung hervorrufen kann. Bei der Gelegenheit werde ich auch erläutern, wie man VMware bei Bedarf genau einem Prozessorkern zuweist.

VMware und Athlon Dual Core Prozessor – Tipp 2

Posted on by

VMware und Athlon Dual Core Prozessoren – Teil 2: CPU-Frequenz unter Linux explizit setzen

Einführung
Im letzten Beitrag
“VMware und Athlon Dual Core Prozessoren – Teil 1”
hatte ich dargestellt, dass auf Doppelcore-Prozessoren einer virtuellen Maschine möglichst nur ein Prozessor-Core zugeordnet werden sollte. Für ein optimales Setup ist dies allerdings noch nicht ausreichend.

So musste ich auf meiner Maschine (Athlon X2 4800, Host Opensuse 10.2, Gast Win XP) leider erleben, dass die Bestimmung der CPU-Frequenz, die VMware beim Starten der virtuellen Maschine vornimmt, keine konstanten Ergebnisse lieferte. Dies galt und gilt auch dann, wenn der virtuellen Maschine nur ein (virtueller) Prozessor zugewiesen wurde. Auch das im VMware Workstation Forum beschworene Abschalten von CPU Throttling und Energiesparoptionen auf Linux-Ebene (Stichwort KPowersave unter KDE) wie auch auf BIOS-Ebene änderten daran leider nichts.

Die im Gastsystem gemeldeten Frequenzwerte der CPU wichen z.T. erheblich von der realen Frequenz der CPU-Cores ab. Ist die Abweichung nach oben (zu hoch geschätzte Freq.) zu groß, kommt es in der Regel zu einem instabilen Verhalten der virtuellen Maschine. Äußere Anzeichen sind etwa ein ruckeliger Cursor, zu schnelle oder ruckartige Buchstabengenerierung etc..

Als Beispiel eine Messreihe, die ich auf meinem Athlon X2 4800 System erhalten habe (Hostsystem Opensuse 10.2, Gastsystem Win XP, VMware WS 6.0):

host: 2.4 GHz -> guest: 2.41 GHz
host: 2.4 GHz -> guest: 2.41 GHz
host: 2.4 GHz -> guest: 2.75 GHz
host: 2.4 GHz -> guest: 2.75 GHz
host: 2.4 GHz -> guest: 3.05 GHz
host: 2.4 GHz -> guest: 2.44 GHz
host: 2.4 GHz -> guest: 2.41 GHz
host: 2.4 GHz -> guest: 3.05 GHz
host: 2.4 GHz -> guest: 2.75 GHz
host: 2.4 GHz -> guest: 2.41 GHz
host: 2.4 GHz -> guest: 2.41 GHz

Genauere Werte mit mehreren Nachkomma-Stellen entnimmt man übrigens dem VMware-Logfile (Dieses findet man für jede virtuelle Maschine in dem Verzeichnis , in dem man die Maschine (besser ihr *.vmx – Konfigurationsfile) angelegt hat. Im aktuellen Log-File suche man nach Einträgen der Art

Aug 15 10:23:20.346: vmx| VMMon_GetkHzEstimate: Calculated 2753892 kHz

bzw. in der guest section des Log-Files
——————————-
Aug 15 10:23:20.850: vmx| KHZEstimate 2753892
Aug 15 10:23:20.850: vmx| MHZEstimate 2754
Aug 15 10:23:20.850: vmx| NumVCPUs 1
Aug 15 10:23:20.850: vmx| KHZEstimate 2753892
Aug 15 10:23:20.850: vmx| MHZEstimate 2754
Aug 15 10:23:20.850: vmx| NumVCPUs 1

Potentielle Fehlerursache
Leider habe ich von VMware keinen konkreten Hinweis darauf erhalten, warum die Frequenzbestimmung nicht zu konstanten Werten führt. Ich vermute aber, dass auch dieses Problem speziell bei Prozessoren auftritt, deren Cores nicht von einer zentralen Einheit aus getaktet werden. Wenn während der Frequenzbestimmung das Hostsystem die VMware-Tasks einem anderen Core zuweist und die Frequenzbestimmung Taktzyklen abfragt, dann kann es in einem solchen Fall natürlich zu fehlerhaften Werten kommen. Aber das ist wie gesagt ein wenig Spekulation ….

Eingrenzung der realen CPU-Frequenz unter Linux
Es wäre zu einfach von einer idealen Frequenz auszugehen. Bei einem Athlon X2 4800 wären dies 2400.000 MHz. In der Realität weicht die tatsächliche Frequenz jedoch immer ein wenig von der idealen Frequenz der Baureihe ab. Folgende Schritte führen zu einer genaueren Frequenzbestimmung mit Hilfe des VMware Log-Files):
1. Mehrere Starts der virtuellen Maschine und Auswahl des Frequenzwertes, der der idealen Frequenz am nächsten kommt und i.d.R. am häufigsten in einer Messreihe auftritt.
2. Bindung der VMware-Prozesse an einen CPU Core vor der Frequenzmessung
r
Hierzu verwendet man das Kommando “taskset”. Also z.B. “taskset -c 0 vmware”. Danach überprüft man die CPU Affinität des gestarteten Prozesses mit “taskset -p pid” (pid ist die Process ID des gestarteten vmware-Prozesses. Bzgl. der Bitmatrix für die CPUs siehe die “manpage” zu “taskset”).

Danach starte man die virtuelle Maschine. In der Prozessübersicht findet man dann weitere VMware Prozesse – u.a. den Prozess “vmware-vmx”. Auch hier überprüfe man die CPU Affinität. Der Prozess sollte dem gleichen CPU-Core zugeordnet sein wie der primäre “vmware”-Prozess. Die dann in der virtuellen Maschine ausgegebenen, geschätzten CPU-Frequenzen (siehe das VMware Log-File!) stimmten bei mir mit dem Wert überein, den die Auswertung einer Meßreihe wie unter 1) beschrieben ergeben hatte.

An dieser Stelle könnte man zu Recht fragen, warum man nicht einfach den Frequenzwert nimmt, den das Linux-System unter /proc/cpuinfo anbietet. (In meinem Fall tauchen da exakt 2400.000 Mhz auf.) Hierauf habe ich nur die Antwort, dass nach meiner Erfahrung die Abweichungen der Uhrzeiten im virtuellen System von der realen Host-Zeit geringer bleiben, wenn man den Frequenz-Wert verwendet, der nach den oben beschrieben Methoden ermittelt wird. (Dies unter der Voraussetzung, dass man in den VMware-Tools die Synchronization der Host und Guest-Zeit nichtaktiviert hat.)

Dauerhaftes Festlegen der CPU-Frequenz für die virtuelle Maschine
Um die CPU-Frequenz als dauerhafte Vorgabe für virtuelle Maschinen festzulegen, muß man das zentrale Konfigurationsfile für VMware bearbeiten. Unter Linux findet man dieses File bei einer Standardinstallation unter /etc/vmware/config. Dieses File ergänzt man um Einträge folgender Art:

host.cpukHz = 2412359
host.noTSC = TRUE
ptsc.noTSC = TRUE

Der angegebene cpukHz-Wert muss natürlich durch den ersetzt werden, den wir durch die obigen Schritte ermittelt haben.
Der erste Eintrag legt die (maximale) CPU Taktfrequenz fest. Die nächsten Zeilen bewirken, dass die Uhrzeit trotz evtl. variierendem Time Stamp Counter (TSC) den richtigen Wert behält. Dies ist wichtig, wenn man Stromspareigenschaften des Systems aktiviert, die zu einem CPU Throttling führen.

Hinweis 1: Ich empfehle, trotz der noTSC-Optionen im config-File Stromsparfunktionen während der Laufzeit von VMware über geeignete Tools des Hostsystems abzuschalten. Wirklich negative Erfahrungen habe ich zwar auch bei aktiviertem CPU-Powersave uind entspr. Frequenzthrottling nicht gesammelt, aber hier folge ich dem Ratschlag der VMware Gurus.

Hinweis 2: In der so konfigurierten Maschine ist eine fixe Zuordnung der VMware-Prozesse zu genau einer CPU (bzw. CPU-Core) nicht erforderlich.

Meine Erfahrungen zur Lastverteilung mit der Workstation 6 unter Opensuse 10.2 ist nach der Vorgabe einer virtuellen CPU und der Vorgabe einer exakten CPU-Frequenz außerordentlich positiv. Auch komplexe Aufgaben unter WIN XP (Adobe Flash, Photoshop, Dreamweaver, …. ) sind auf einem AMD X2 4800 Prozessor problemlos unter VMware mit einer (virtuellen) CPU ausführbar. Beobachtet man das System genau, so gewinnt man den Eindruck, dass VMware Overhead (z.B. Vorbereiten von Extends der virtuellen Platte und zugehörige Dateioperationen im Linux-File-System; Netzwerkoperationen) bei Bedarf trotzdem durch den zweiten Prozessor-Core erledigt wird.

Für meine Diskussion mit VMware siehe:
http://communities.vmware.com/message/724123#724123

Lokale Suchmaschine für Websites I

Posted on by

Einführung
Bei der Erstellung von Websites – auch kleineren Umfangs – kommt von Kunden immer häufiger die Anforderung eine kleine Suchmaschine zu integrieren, die zu einem oder einigen wenigen Suchbegriffen die relevanten Seiten der Website findet.

Da dies eine Standardaufgabe ist, hofft man als Entwickler, im Internet nicht nur fertige und freie OpenSource Suchmaschinen sondern auch Hinweise darauf zu finden, wie man einen solchen Service evtl. selbst programmiert. Interessanterweise liefert eine Internetrecherche im nichtkommerziellen Bereich gar nicht so viele passende Treffer. Fast verschwindend ist die Anzahl brauchbarer Anleitungen zum Eigenbau mittels PHP. Der oft zu findende Hinweis, man möge doch bitte die Volltextindizierung von MySQL benutzen, nützt einem ohne entsprechendes Hintergrundswissen zunächst auch nicht so viel.

Eine an und für sich gelungene Einführung von Daniel Solin
http://www.onlamp.com/pub/a/php/2002/10/24/simplesearchengine.html?page=1

leidet darunter, dass sich die Ausführungen auf eine Beispielmaschine beschränken, die genau einen Suchbegriff zulässt.

Da wir selbst in einem unserer letzten Aufträge eine Suchmaschine implementieren mussten, möchten wir mit einigen Tipps und Programmhinweisen die Diskussion von Daniel Solin erweitern und ergänzen.

Zielsetzung ist dabei Folgendes:

1. Eine kurze Diskussion einer möglichen Strategie zur Bestimmung der “Relevanz” einer getroffenen Seite. Eine solche Diskussion fehlt im Artikel von Solin; die Relevanz einer getroffenen Seite wird aber immer wichtiger, wenn bei der Suche mehr als ein Suchbegriff verwendet wird.
2. Eine Darstellung des Programmablaufs zur Erstellung der Datenbank.
3. Eine Darstellung des Programmablaufs für den Suchvorgang selbst, wenn genau ein Suchbegriff eingesetzt wird.
4. Erweiterung der Suche auf mehrere Suchbegriffe, wobei die Begriffe in exakter Schreibweise gefunden werden sollen.
5. Erweiterung des Programmablaufs für eine unscharfe Suche.

Wir werden diese Punkte in einzelnen Blog-Artikeln aufgreifen und hoffen, damit dem einen oder anderen Webseiten-Entwickler, der den Einsatz von PHP nicht scheut, eine Hilfestellung zu leisten.