nicht angemeldet
Zugunsten der Performance Coden
Hallo Forum,
in meinem selbst gezimmerten PHP-CMS gibt es eine "Seitenübersicht".
Auf dieser Seite werden die ca. 600 Seiten und verschiedene derer
Eigenschaften in einer TreeTable dargestellt. Das sieht in etwa
so aus:
http://sstree.tigris.org/nonav/example4.html#
Der Aufbau der Tabelle dauert ewig und ich mache mir Gedanken, wie
ich die Performance steigern könnte. Die PHP-Logik, nach der die
Tabelle aufgebaut wird ist allerindgs komplex. Sonst würde ich es
selbst ausprobieren.
Was würdet Ihr sagen, ist auf Clientseite das perfomanteste ? Eine
<table> -Konstruktion scheint es nicht zu sein. Man könnte das
sicher mit einem <ul>-Konstrukt und in den <li>-Tags mit <div>-Elementen hinbekommen. Aber ist das wesentlich schneller ?
Oder sollte ich ganz umdenken und nach einer Ajax-Anwednung
ausschau halten, die erst beim Aufklappen Contents nachläd ?
Hat jemand einen Tipp für mich ?
beste gruesse,
maritn
-
Hi,
Der Aufbau der Tabelle dauert ewig und ich mache mir Gedanken, wie
ich die Performance steigern könnte.kleiner Tipp: Höchstwahrscheinlich nicht mit clientseitigen Aktionen.
Was würdet Ihr sagen, ist auf Clientseite das perfomanteste ? Eine
<table> -Konstruktion scheint es nicht zu sein. Man könnte das
sicher mit einem <ul>-Konstrukt und in den <li>-Tags mit <div>-Elementen hinbekommen. Aber ist das wesentlich schneller ?Ich bin mir sicher, dass ein Benchmark, der die tatsächlich _clientseitig_ benötigte Zeit misst, kaum nennenswerte Unterschiede finden wird.
Oder sollte ich ganz umdenken und nach einer Ajax-Anwednung
ausschau halten, die erst beim Aufklappen Contents nachläd ?Vielleicht solltest Du erstmal herausfinden, was der eigentliche Performance-Killer ist.
Hat jemand einen Tipp für mich ?
Leere am Ende der Script-Abarbeitung den Output Buffer und messe den Geschwindigkeitsunterschied. Dann weißt Du, ob der Client eine Rolle spielen kann. Grenze anschließend weiter ein.
Cheatah
--
X-Self-Code: sh:( fo:} ch:~ rl:° br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes-
Hi,
wenn ich Dich richtig verstanden habe, würdest Du die die
schlechte Performance serverseitig vermuten oder anders
ausgedrückt PHP braucht lange, um die Seite zu generieren.Berichtige mich bitte, wenn ich Dich falsch vertanden habe.
Ich hab folgenden Test gemacht:
Die von php generierte index.php habe ich im Browser aufgerufen
und abgewartet, bis die fertig geladen im Browser angezeigt
wurde. Den Quelltext der Seite habe ich als index.html neben
der dynamischen idex.php auf dem Server abgespeichert.Ich setze auf der Seite ein Script ein, dass den Auf- und
Zuklappmechanismus übernimmt. OnLoad="init()" sorgt dafür
dass die Tabelle zugeklappt wird. Das soll mein Indikator
für "Seite fertig geladen sein".Ungeachtet des Cache habe ich jetzt beide Seiten nacheinander
aufgerufen und die Zeit bis "vollständig geladen" gestoppt.
(Der Server ist definitiv nur mit den Seiten beschäftigt)PHPgenerierte Seite 'index.php' : 01:37 Minuten
Statische Seite: 'index.html' : 01:35 MinutenIch finde das nervtötend langsam und frage mich, ob ich den
Code so optimieren kann, dass das merklich besser wird.beste gruesse,
martin-
Hi,
wenn ich Dich richtig verstanden habe, würdest Du die die
schlechte Performance serverseitig vermuten oder anders
ausgedrückt PHP braucht lange, um die Seite zu generieren.aufgrund der Beispielseite, die Du nanntest, ging ich davon aus, ja.
Ich setze auf der Seite ein Script ein, dass den Auf- und
Zuklappmechanismus übernimmt. OnLoad="init()" sorgt dafür
dass die Tabelle zugeklappt wird. Das soll mein Indikator
für "Seite fertig geladen sein".Guter Messpunkt. Für "Seite beginnt angezeigt zu werden" gibt es leider keinen ähnlich geeigneten Zeitpunkt; am ehesten könntest Du im <head> ein JavaScript unterbringen, das (mit minimalem Code) hierzu dient. Misst Du den Endpunkt vor oder nach dem Zuklappen?
Ich finde das nervtötend langsam und frage mich, ob ich den
Code so optimieren kann, dass das merklich besser wird.Bei anderthalb Minuten verstehe ich das gut. Leider kann ich das Problem hier nicht nachvollziehen; Deine Testseite ist schnell.
Cheatah
--
X-Self-Code: sh:( fo:} ch:~ rl:° br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes-
Hi,
Guter Messpunkt. Für "Seite beginnt angezeigt zu werden" gibt es leider keinen ähnlich geeigneten Zeitpunkt; am ehesten könntest Du im <head> ein JavaScript unterbringen, das (mit minimalem Code) hierzu dient. Misst Du den Endpunkt vor oder nach dem Zuklappen?
Das Zuklappen dauert eine Sekunden und, danke für den Hinweis,
aber ob der Messpunkt wirklich heisst, dass die Seite nun
wirklich vollständg geladen ist, spielt eigentlich keine Rolle.
Nach dem Zuklappen, kann ich sie bedienen:Viele der Aktionen auf der Seite haben ein Datenbankupdate zur
Folge, damit einer inhaltliche Veränderung und entsprechend
einen Reload zur Folge.Beispiel:
---------
Jede Zeile stellt eine Seite bzw. einen Datensatz dar. Ein
dargestelltes Detail eines sollchen Datensatzes ist das
Aktualisierungsdatum. Ausserdem gibt es in der Zeile einen
Button aktualisieren. Wenn ich also einen Datensatz
aktualisieren will klicke ich den Button und die Seite läd
neu. Wenn ich mal 10 Datensätze nacheinander aktualisieren
muss, sollte ich mir überlegen, ob ich dafür vielleicht
einen Chimpansen abrichten sollte ;)Lösung:
-------
Ich hätte das eigentlich anders lösen sollen und auch die
Monstertabelle verzichten. Hab ich aber nicht, weil mir
nicht klar war, wie lange der Seitenaufbau dauert. Jetzt
habe ich das Problem, dass ich einen anderen Aufbau schwer rechtfertigen kann. Deshalb würde ich mit Kanonen auf
Spatzen schiessen (jedenfalls erscheint es mir so) und
eventuell nach einer Ajax-Lösung streben, um den Aufbau,
bzw. die Bedienung nicht zu verändern.Hast Du Erfahrungen mit sollchen Frameworks. Kannst
Du da eine Empfehlung aussprechen ?danke und
beste gruesse,
martin -
Hi,
Bei anderthalb Minuten verstehe ich das gut. Leider kann ich das Problem hier nicht nachvollziehen; Deine Testseite ist schnell.
Ich hätte die Testseite zum Draufgucken gerne bereit gestellt
und mich riesig gefreut, wenn sich das jemand aussehstejendes
von hier mal angesehen hätte. Allerdings steckt die so voller
vertrauenswürdiger Daten, dass es einige Arbeit gemacht hätte,
diese alle zu finden und unkenntlich zu machen.Ich habe aber neue Erkenntnisse:
In den Tabellenzeilen gibt es jeweils 5 Buttons, die als
<a href=""><img src=""></a> im Code stehen. In den 1:30
Minuten schaue ich vor Allem zur dabei zu, wie von den
600*5=3000 Buttons einer nach dem anderen angezeigt wird.
Da es aber nur 5 verschiendene sind, würde ich denken die
werden ge-'cached' und sollten damit keine Problem mehr
sein. Es sieht aber anders aus. Und siehe da:Alle Buttons ausgeblendet:
Das Laden der Seite dauert 0:18 Minuten
Da ich die Buttons aber nunmal brauche, kann ich mir nur vorstellen,
die Buttons als bg-grafik im css zu definieren. Aber dass das hilft,
glaube ich auch noch nicht so wirklich.erstmal
beste gruesse,
martin-
Hi Martin,
Da ich die Buttons aber nunmal brauche, kann ich mir nur vorstellen,
die Buttons als bg-grafik im css zu definieren. Aber dass das hilft,
glaube ich auch noch nicht so wirklich.Oh je, die Feststellung hab ich vor einiger Zeit auch schon gemacht - viele Formular-Elemente (Buttons, Eingabefelder, Select-Boxen, etc.) führen zu einer enormen Verlangsamung des Seitenaufbaus.
Das Einzige was du hier machen kannst: Du musst die Buttons alle rausschmeißen und durch etwas geeigneteres Ersetzen, z.B:
- normale Links anstelle der Buttons verwenden, die z.B. auf
script.php?record=54&action=delete verweisen - einen "Bearbeiten"-Link, der zu einer neuen Seite mit den Buttons für
speziell diesen Eintrag führt - mit Javascript arbeiten, also den Eventhandler onclick verwenden und
die Daten per AJAX an den Server senden
Die Vor- und Nachteile der Alternativen musst du halt für dich entsprechend abwiegen.
Viele Grüße,
~ Dennis.-
Hallo Dennis,
Oh je, die Feststellung hab ich vor einiger Zeit auch schon gemacht - viele Formular-Elemente (Buttons, Eingabefelder, Select-Boxen, etc.) führen zu einer enormen Verlangsamung des Seitenaufbaus.
Mit Buttons sind keine Formularelemente gemeint, sondern:
'<a href=""><img src=""></a>Das Einzige was du hier machen kannst: Du musst die Buttons alle rausschmeißen und durch etwas geeigneteres Ersetzen, z.B:
- normale Links anstelle der Buttons verwenden, die z.B. auf
script.php?record=54&action=delete verweisen - einen "Bearbeiten"-Link, der zu einer neuen Seite mit den Buttons für
speziell diesen Eintrag führt - mit Javascript arbeiten, also den Eventhandler onclick verwenden und
Genau das war meine Frage, bevor ich sämtliche möglichen HTML-
Konstrukte ausprobiere und jeweils hinterher messe, ob und um
wieviel sich die Ladezeit verbessert, wenn ich z.B. das a-Tag
gegen ein onclick im übergeordneten Element austausche. Ich
habe den Verdacht, dass sollche Massnahmen wirklich etwas
bringen und um eine deutliche Performance-Steigerung zu erreichen
etwas wie:die Daten per AJAX an den Server senden
... unumgänglich ist. Damit kenne ich mich nämlich nicht aus.
Klar könnte man sagen, so etwas gibt's ja schon. Das kann man
nutzen, ohne sich wirklich damit auszukennen. Aber dann besteht
die Aufgabe m.E. darin, ausser das fertige zu konfigurieren vor
allem darin, etwas fertiges zu finden, dass passt und das man
bei der nächsten Anforderung wieder nutzen kann. Es gibt da ja
Lösungen, die Geld kosten, sicher genauso gute freie Lösungen.
Welche set6zt sich durch und wird weiterentwickelt ?Was bedeutet 'Ajax' für Dich ? Hast Du die technik an sich
gelernt oder setzt Du etwas fertiges ein und wenn dann was ?danke und
beste gruesse,
martin-
Hi Martin,
Mit Buttons sind keine Formularelemente gemeint, sondern:
'<a href=""><img src=""></a>Das darf eigentlich nicht so lange zum Laden brauchen… Nimm doch das Bild testweise mal raus und ersetze es durch einen simplen Text. Lädt die Seite damit schneller?
Falls dem so ist, solltest du zuerst prüfen, ob das Bild vom Browser erfolgreich gecached wird, wenn der Browser das gleiche Bild für jede Anzeige einzeln abrufen muss, ist das natürlich äußerst suboptimal. Auch wäre hier sinnvoll direkt height und width für das Bild anzugeben, damit der Browser nicht nach dem Laden des Bilder die Seite neu aufbauen muss, sondern von vorher her den notwendigen Platz freihalten kann.
Genau das war meine Frage, bevor ich sämtliche möglichen HTML-
Konstrukte ausprobiere und jeweils hinterher messe, ob und um
wieviel sich die Ladezeit verbessert, wenn ich z.B. das a-Tag
gegen ein onclick im übergeordneten Element austausche.Ich weiß nicht so recht… an einen extremen Performance-Gewinn kann ich nicht glauben, einfache Text-Links sind nur wirklich so ziemlich das simpelste, was es gibt - warum sollte es also schneller sein, durch Javascript-Manipulationen eine Reaktion zur Seite hinzuzufügen? Abgesehen davon würdest du durch reines Javascript natürlich die Usability deiner Seite stark einschränken.
die Daten per AJAX an den Server senden
... unumgänglich ist.
Kommt drauf an, was sollen diese Links überhaupt bewirken? Ich stelle mir das gerade so vor:
Max Mustermann [Details bearbeiten] [Passwort zurücksetzen] [Account löschen]
Thomas Müller [Details bearbeiten] [Passwort zurücksetzen] [Account löschen]In diesem Fall würde der Einsatz von AJAX nicht allzu viel Sinn machen. Die Funktion „Account löschen” lässt sich prima ohne AJAX realisieren, für „Passwort zurücksetzen” würde ich ebenfalls eine eigene Seite machen, lediglich für „Details bearbeiten” könnte man über Textfelder den Namen ändern und anschließend an den Server senden lassen.
Aber was in deinem Fall empfehlenswert ist, lässt sich nur sagen, wenn du uns etwas genauer erzählst, was du vorhast.
Was bedeutet 'Ajax' für Dich ? Hast Du die technik an sich
gelernt oder setzt Du etwas fertiges ein und wenn dann was ?Ich verwende Prototype.js als Javascript-Framework, alles was ich brauche, habe ich aus den API-Docs und den Beispielen dort gelernt. Prototype nehme ich unter anderem, weil Scriptaculous darauf aufbaut, was ich derweil schon mal für Effekte benutzt habe. Allerdings ist Prototype recht mächtig und teilweise überdimensioniert.
Natürlich kannst du dich auch für ein anderes Framework, wie z.B. jQuery entscheiden, welches AFAIK hier im Forum zum Einsatz kommt. Über die Vor- und Nachteile unterschiedlicher Frameworks informierst du dich am besten durch Recherchen hier im Forum oder bei Google.
Viele Grüße,
~ Dennis.
- normale Links anstelle der Buttons verwenden, die z.B. auf
- normale Links anstelle der Buttons verwenden, die z.B. auf
-
Moin!
In den Tabellenzeilen gibt es jeweils 5 Buttons, die als
<a href=""><img src=""></a> im Code stehen. In den 1:30
Minuten schaue ich vor Allem zur dabei zu, wie von den
600*5=3000 Buttons einer nach dem anderen angezeigt wird.
Da es aber nur 5 verschiendene sind, würde ich denken die
werden ge-'cached' und sollten damit keine Problem mehr
sein. Es sieht aber anders aus. Und siehe da:Alle Buttons ausgeblendet:
Das Laden der Seite dauert 0:18 Minuten
Kannst du die Datei nicht auf deinem Server temporär erstellen lassen und erst an den Browser ausliefern, wenn sie komplett fertig ist?
Ich vermute, daß der Browser nicht nachkommt, weil er bei jeder Änderung die gesamte bisherige Seite neu rendern muß.Cü,
Kai
--
What is the difference between Scientology and Microsoft? One is an
evil cult bent on world domination and the other was begun by L. Ron
Hubbard
ie:{ fl:( br:< va:) ls:? fo:| rl:? n4:° ss:{ de:] js:| ch:? mo:| zu:|]
-
-
-
Hi,
wenn ich Dich richtig verstanden habe, würdest Du die die
schlechte Performance serverseitig vermuten oder anders
ausgedrückt PHP braucht lange, um die Seite zu generieren.Cheatah wollte das wohl zumindest als Ursache ausschliessen koennen - deshalb sein Vorschlag, wie man das messen koennte.
Ich setze auf der Seite ein Script ein, dass den Auf- und
Zuklappmechanismus übernimmt. OnLoad="init()" sorgt dafür
dass die Tabelle zugeklappt wird. Das soll mein Indikator
für "Seite fertig geladen sein".Wie lange dauert denn das Laden und Darstellen der Tabelle, wenn du den Zuklapp-Kram erst mal weglaesst - geht das fix, oder brauchen der/die Browser auch schon alleine zum Rendern der Tabelle "ewig"?
Ich finde das nervtötend langsam und frage mich, ob ich den
Code so optimieren kann, dass das merklich besser wird.Wenn sich das Zuklappen als Bremse herausstellen sollte, kann man schauen, ob sich das optimieren laesst.
Peter-Paul Koch hat auf quirksmode.org dazu mal einen Benchmark - style vs. className erstellt. Aenderungen des classNames von Elementen haben sich dabei als idR. schnellere Alternative zur Manipulation einzelner style-Eigenschaften von Elementen erwiesen (ausser im Safari, der aus der Reihe faellt).MfG ChrisB
-
-