Only visible to XING members.

Performance Steigerung

Also, dann plauder ich mal ein bissl was zu meinen Projekten aus...
Die bei mir eingesetzten Frontends arbeiten in der Regel mit XSLT als Template-Sprache. Darunter liegt eine irgendwie geartete XML-Datenlayer mit einem sehr simplen (und daher konsistenten) Schema aus 1) <group />s, <item />s und <fragment />s
Dabei spielt es eigentlich keine Rolle was unter dieser Datenschicht liegt: ein Framework, eine eigene Code-Basis, etc. wo möglich werden XML-Daten als Flatfiles im Dateisystem abgelegt (je weniger desto besser). Sprich: das Backend ist darauf ausgelegt, solche statischen Files bei Änderungen auch zu aktulaisieren. Damit vermeide ich außerdem unnötige Datenbankzugriffe.
Dynamische Teile einer Applikation (Formulare) müssen natürlich in Echtzeit XML an den XSLProzessor liefern.
Außerdem kompilieren wir PHP mit XSLCache von der New York Times, die auf den nativen PHP XSLT Prozessor ersetzt und etwa um den Faktor 10 schneller ist.
Cachedateien werden als hash über alle Reqeust-Parameter angelegt und bei Bedarf gelöscht (Update einer Seite im Backend, oder über SVN Hooks).

Ein paar Vorteile dieser Architektur aus meiner Erfahrung:
- mit meist geringem Aufwand kann ein AJAX Controller Teile einer XML-Datei im Dateisystem ausspucken ( - auch wenn JSON etwas kompakter wäre). Im Endeffekt werden XML Daten die zur Generierung von ganzen Seiten benutzt werden so einfach recycled.
- die eigentliche Funktionsweise der Applikation/Frontend/etc. bleibt hinter dem XSL Prozessor verborgen.
- einfache Aufteilung von Teilen der Applikation auf mehrere Server. (Backend/Frontend/DBServer/etc.). Selbst Statistiken können als Service mit dem <script> Element laufen.
- auch wenn sich XSLT in Website Frontends nie wirklich durchgesetzt hat, macht es in meinen Augen Sinn. Gerade der Code profitiert von einer sauberen Trennung zwischen Präsentations- und Daten-Layer.
- Da alle verwendeten Services ebenfalls eine XML API/Response haben lassen sich diese ebenfalls simpel in den XSLT einbinden.

Suat Özgür Suat Özgür

Hallo Welt

"Im Durchschnitt benötigen Seiten auf Ihrer Website 3,1 Sekunden zum Laden (aktualisiert am 19.01.2011). Dies ist langsamer als 52 % der Websites.", sagen mir die google Webmaster-Tools und das kratzt ganz schön an meinem Entwickler-Ego. Damit wäre dann wohl auch geklärt, weshalb ich hier gelandet bin :)

Momentan beschäftigen mich besonders Fragen wie "Apache oder nginx?", "Sind CDNs wirklich schneller?", "Inwiefern sind abhängige CSS Selektoren ineffizient?", "Beeinflusst die Performance tatsächlich mein Google Ranking?" oder "Wie in aller Welt kommt Google auf 3,1 Sekunden?"

Ich freue mich auf den Erfahrungsaustausch :)

Suat

Thomas Puppe Suat Özgür
+2 more comments
Last comment:
Thomas Puppe Thomas Puppe Premium

Re^2: Heikle Fragen

Die Erfahrungen mit CDN kann ich bestätigen. Ich sehe die Vorteile eines CDN nicht für alle Seiten, sondern nur bei (a) internationalen Besuchern, die so eine Chance haben, dass der Content in ihrer Nähe gehostet wird (b) vielen parallelen Downloads. Meine Erfahrung ist, dass man bei den CDN sehr lange auf eine Response wartet, und die eigentliche Übertragung der Daten dann sehr schnell geht.

Die CSS- und JS-Selektoren kann man natürlich mit einschlägigen Tipps verbessern (etwas unbekannter: http://net.tutsplus.com/tutorials/javascript-ajax/quick-tip-think-right-to-left-with-jquery ). Allerdings ist der Effekt bei normalen Seiten marginal. Ob der Browser zum Finden von $('myId') 0,0002s oder für getElementById('myId') 0,00015s braucht, ist normalerweise zu vernachlässigen und nur für massenhaftes Selektieren in Schleifen relevant.

Only visible to XING members.

Servus.

Erik mein Name. Web Entwickler mit Fokus auf PHP, XML & XSLT sowie jQuery. Performance Optimierung interessiert mich sehr. Freue mich also sehr über diese Gruppe.
Wo ich in der Praxis immer wieder Probleme habe ist der Punkt Javaskript Deployment. Also nicht so sehr das Schreiben performanter Javaskripte, als vielmehr das mergen/compilen/gzippen/cachen/benchmarken, etc.
Da erhoffe ich mir hier ein paar Tips aus anderer Leut Praxis.

Suat Özgür
+2 more comments
Last comment:
Only visible to XING members.

Re^2: JavaScript

Suat, Danke für deinen Beitrag, da nehm ich Einiges mit.
Ich habe bisher mit Minify, dem DOJO Compressor, Dean Edward's packer und zuletzt mit Google Closure Compiler gearbeitet. Aber eigentlich auch nur aus der Not heraus, weil in manchen Webseiten alte scriptaculous Skripte drin waren die sich mit Minify nicht komprimieren liessen, oder weil irgendwelche anderen Skripte eingebunden wurden die in JSLint komplett abrauschen aber keine Zeit ist Funktionalitäten mal eben in seinem Lieblingsframework neu zu schreiben.
Außerdem habe ich meine ganzen (PHP basierten) Lösungen für diese Kompressoren auch nicht ordentlich zusammengebracht - auch von Webseite zu Webseite sind die Lösungen unterschiedlich.

zu 1) meine Zeile sieht so aus: java -jar compiler.jar --compilation_level ADVANCED_OPTIMIZATIONS --jscomp_dev_mode START --js /var/www/merged-scipts.js --js_output_file /var/www/scripts.min.js
wobei ich es nicht hinbekommen habe mehrere files in einem Aufwasch zu komprimieren. Also alles in PHP. erst mergen, dann mit exec() das tempfile komprimieren.

zu 3) dieses umbenennen der Dateien oder dieser Extra Dateizugriff um die filemtime zu prüfen oder und um einen Parameter anzuhängen oder um automatisch das Neukomprimieren anzustubsen würd ich gern vermeiden. Gefährlich ist da irgendwie auch sobald man die HTML Dokumente irgendwie cached und von dort an den Browser schickt. Dann muss man also auch noch den Cache leeren. etc.

Die getallheaders() Funktion in PHP ist mir komplett neu. Ist das ein Conditional GET? Ich habe sowas ähnliches schonmal in Zusammenhang mit RSS-Feeds gesehen, die ja u.U. auch recht groß werden können.

Und wenn man dann alles richtig gemacht hat. Gemerged, Komprimiert, mit gzip und sonstigen Expires-, Lastmod-, HTTP Status-Headern gesendet, dann ist da noch dieser subjektive Flaschenhals des Dekomprimierens der Skripte im Browser. Subjektiv, aber nicht getestet. Da gibt es wohl auch keine wirkliche Möglichkeit für Benchmarks, oder? Die Performance des entpackens von gzip und ggf. dekomprimieren des JS (Dean Edwards Packer hat eine Dekomprimieren Funtion) hängt ja von der Performance des Computers/Smartphone/Netbook etc. ab.
Gehts anderen da ähnlich? Was ist ein gutes Kompressionslevel für gzip?
Da ist zwar YSlow happy, aber....

Benutzt ihr für CSS und JS grundsätzlich denselben Kompressor? Minify ist für CSS insofern mein Favorit als dass es in Sachen Header, Gzipping, mergen alles für einen übernimmt.

Was wir tun, ist alle Libraries und Plugins als unkomprimierte Einzeldateien einzubinden. Sei es jQuery Tools oder jQuery UI oder Plugins. Statt der kompletten Bibliothek nur noch die Effekte/Funktionen/Apps die auch wirklich eingesetzt werden. Als Dateiliste in einer Art Konfigurationsdatei im XML Format. zB http://snipplr.com/view/45852/compiling-js-with-closure-compiler-and-php/

Noch ein Punkt ist das Debugging, was ja mit der kompilierten Datei unmöglich ist. Nutzt ihr zum debuggen einfach die Entwicklungsumgebung oder einen URL-Parameter der stattdessen die Einzelskripte einbindet, oder gibt es noch andere Varianten?