Hallo. Wir überlegen im Moment, unser Hosting-Paket auf dem die ShopWare laufen soll etwas zu pimpen. 
Was sind denn so die Eckdaten welche die Performance von ShopWare pushen? Was macht wirklich was aus? Wie viel macht da der Prozessor aus? Denn beim Prozessor haben wir demnächst ohnehin ein upgrade von 8 User/CPU auf 2 User/CPU. Wird man das gut merken oder ist der Prozessor gar nicht so wichtig? Danke derweil … AS
Das ist pauschal schlecht zu beantworten. Letztlich machen alle beteiligten Komponenten etwas aus. Den Apache z.B. kann man etwas tunen, PHP mit einem Cache ausrüsten, die MySQL Einstellungen lassen sich auch analysieren und tunen und mit viel CPU und Speicher, sowie schnellen Platten ist der Effekt entsprechend größer. Auch bei Shopware selbst läßt sich z.B. über das Laden statischer Inhalte von verschiedenen Subdomains noch etwas machen, allerdings braucht man da bei https-Einsatz ein Wildcart-Zertifikat. Nicht zuletzt sollten Bilder/CSS/JS auch schon entsprechend klein sein. Da müßte Shopware mit ihrer /templates/_default/frontend/_resources/javascript/jquery.shopware.js und 140KB auch noch etwas tun. Das läßt sich zwar per http gzip-komprimieren, allerdings schlägt das Minifying mit bisher allen von mir eingesetzten Tools fehl. Die jquery-1.4.2.js dagegen kann man prima mit durch die minified-Version austauschen. Die Frage ist hier eher: Welche Antwort-/Ladezeiten will ich erreichen und an welchen Schrauben kann ich überhaupt drehen, wenn ich keinen eigenen root-Server habe, sondern ein Hosting-Angebot nutze? Ich kann gern mal ein paar Configs / Tipps veröffentlichen, die ich auch schon in größeren Firmen im Webbereich implementiert habe. Natürlich gelten die dann nur sehr eingeschränkt für Hosting-Lösungen. Vielleicht läßt mich Shopware ja auch ein Tutorial schreiben?!
3 „Gefällt mir“
Hey, Du kannst da gerne mal ein Tutorial schreiben! Viele Erfahrungswerte sind natürlich immer gut. Und das ist ja eh kein reines Shopware Thema, sondern betrifft primär Performance Optimierungen für den Server / DB und Co. Natürlich liegt es auch am eingesetzten Paket, also ob man 5 €, 50 € im Monat oder so wie wir für einen Server über 1000 € / Monat zahlt…
Okay aber auf unserem Server laufen ja auch hunderte Shops. Man kann aber ja auch an kleinen Paketen so einiges optimieren, z.B, auch durch eAccelarator und Co. und Deinen Ansätzen… Gruß Stefan
Ich mache das mal in kleinen Häppchen: Vorwort Bei diesem Tutorial wird folgendes vorausgesetzt: [list] [*] Apache 2.2.x, PHP5, MySQL 5.1.x und Shopware 3.5.x sind installiert und laufen bereits einwandfrei zusammen.[/*] [*] Grundsätzliches Wissen über das Installieren von Paketen auf dem Betriebssystem[/*] [*] Root-Rechte bzw. Vollzugriff auf Configs und die Start-/Stopscripte von Apache und MySQL[/*] [*] Ihr wißt, wo sich Eure Konfigurationsdateien für Apache2 und MySQL befinden und wie ihr beide durchstartet[/*] [*] Ihr wißt, wo Eure php.ini liegt[/*] [*] Firefox mit installiertem Firebug Add-On zur Überprüfung der Ergebnisse[/*][/list] Kommandos und Pfade werden sich auf eine Linux Shell unter Debian Squeeze beziehen. Auf anderen Linux-Systemen sind sie leicht anzupassen. Schritt 1: Apache und PHP Versionsnummern entfernen Der erste Schritt hat mit Tuning eigentlich nichts zu tun, wird aber in produktiven Systemen gern vergessen und gibt potentiellen Angreifern nützliche Tipps, wie Eure Umgebung aussieht. Zunächst öffnen wir mal Firefox und aktivieren Firebug (und das Netzwerk) und laden Eure Shop-Startseite, z.B.: http://www.meineshopdomain.de In Firebug jetzt auf das Pluszeichen links neben die erste URL klicken und wir sehen den http Antwort-Header des Apache. Interessant sind in diesem Schritt zwei Zeilen: Server Apache/2.2.16 (Linux) PHP/5.3 with Suhosin-Patch undweiterenetteinfos... X-Powered-By PHP/5.3.3 Abhilfe: - Apache Config öffnen und Zeile ServerTokens suchen den Eintrag wie folgt modifizieren: ServerTokens Prod - php.ini öffnen und Zeile expose_phh suchen und den Eintrag auf Wert Off stellen: expose\_php = Off Jetzt noch den Apache durchstarten, z.B. so: /etc/init.d/apache2 restart … und das Ergebnis durch Neuladen in Firebug überprüfen: Voilà, die X-Powered-By Zeile ist weg und der Server sagt nur noch “Apache”. P.S.: das X-Powered-by PHP 5.2.14 müßte Shopware auch mal entfernen
Hey, cool. Danke! Wenn du willst, mache ich davon eine kleine Artikelreihe direkt im Wiki - dann müsstest du mir mal eben eine PM schicken. An das Thema wollte ich sowieso in den nächsten Wochen gehen, also z.B. auch die Einrichtung von Memcache und generelle Server-Optimierungen die man angehen kann…
Schritt 2: Übertragung textbasierter Inhalte gzip-Komprimieren mit mod_deflate Gerade ein Shopsystem wie Shopware kommt nicht ohne größere Javascript- und CSS-Dateien aus. Allein die jquery.shopware.js hat 135KB und läßt sich z.Zt. auch leider nicht mit einem Minifier verkleinern. Auch der Inhalt der aus PHP erzeugten HTML-Datei hat immerhin ca. 17KB. Je nach Stylesheet gehen damit insgesamt bereits über 350 Kilobyte Daten über die Leitung, ohne dass auch nur ein Hintergrundbild, Banner oder Produktbild angezeigt wird. Das läßt sich bei der Übetragung auf ca. 90KB eindampfen. Wie? Mit mod_deflate! Das Modul ist in einer Standardinstallation von Apache2 bereits enthalten, allerdings meist inaktiv. Aktivierung: a2enmod deflate Für die Konfiguration brauchen wir noch ein zweites Apache Modul, das den http-Header verändern kann: a2enmod headers Bevor wir jetzt den Apache durchstarten und die Änderungen aktiv machen, nehmen wir uns die Config-Datei des deflate Moduls vor, die in einer Debian Standardinstallation jetzt unter /etc/apache2/mods-enabled/deflate.conf verlinkt sein sollte. Den Inhalt detailliert zu erklären, würde sehr weit führen. Nur soviel: Wir Komprimieren alle textbasierten Inhalte anhand des Typs (MIME-Type), schließen bei uralt-Versionen den Microsoft IE für die Kompression einiger Typen aus und geben danach den Proxy-Servern dieser Welt die Chance, die Inhalte sauber zu erkennen: [code]
DeflateCompressionLevel 6
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/atom_xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/x-httpd-php
AddOutputFilterByType DEFLATE application/x-httpd-fastphp
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
<ifmodule mod_headers.c>
Header append Vary User-Agent env=!dont-vary
</ifmodule>
[/code] Danach starten wir den Apache durch: /etc/init.d/apache2 restart …und überprüfen mit Firebug wieder das Ergebnis, indem wir die Shopseite komplett neu laden (mit leerem Cache bzw. SHIFT-Reload). Die textbasierten Dateien dürften jetzt nur noch ca. 25% der ursprünglichen Größe haben. Ganz genau sieht man den Vergleich, wenn man zusätzlich Firefox Add-on Page Speed von Google installiert und hier auf „Resources“ klickt, denn hier wird für jede Datei „File Size“ und „Transfer Size“ angegeben. Letztere haben wir gerade optimiert.
Schritt 3: Dem Browser Caching-Zeiten mitgeben Hier muss ich leider ein klein wenig ausholen, denn das Browser-Caching wird gern falsch verstanden und noch lieber falsch gemessen. Auch gibt es leider mehrere Methoden, dem Browser Caching Informationen zu übermitteln. Ich beziehe mich auf die, die man bei der Übertragung vom Server zum Client/Browser im http-Header mitgibt. Leider gibt es hier auch mehrere Methoden. Http-Elemente / Dateien / Requesttypen Eine Website besteht zumeist aus dutzenden Einzelelementen, die vom Browser geladen werden. Die Shopware Startseite besteht bereits ohne Artikelbilder und ohne Banner je nach Template aus gut 30 Einzelelementen. Damit die nicht bei jedem Seitenaufruf immer komplett neu geladen werden müssen, hat jeder Browser einen lokalen Cache auf der heimischen Festplatte und überprüft bei jedem Aufruf eines Elements, ob er entweder: a) das Element/die Datei komplett neu anfordern muss und der Server liefert die komplette Datei aus. Das ist z.B. bei einem „force-Reload“ (SHIFT und neu laden) im Browser der Fall. Der Server gibt den Statuscode „200“ zurück und schickt die komplette Datei. Das ist der ungünstigste Fall, bei einem Erstbesuch einer Site aber nicht zu vermeiden. Interessant ist das Verhalten daher erst ab der zweiten Seite bzw. ab dem zweiten Besuch der Site. b) oder das Element, das bereits im lokalen Cache liegt, noch aktuell ist. Diese Anfrage geht also mit einem Zeitstempel („If-Mofified-Since “) und einem Tag („If-none-Match “) an den Server. Hat der Server diese Datei mit demselben Zeitstempel, gilt sie als unverändert und der Server liefert statt der kompletten Datei nur einen Statuscode „304“ (not modified) zurück und der Browser weiß, dass er diese Datei aus seinem Cache anzeigen kann, was Ladezeiten spart. Das ist z.B. bei einem „neu laden“ einer bereits angezeigten Seite der Fall. Trotzdem muss der Server angefragt werden und der Server muss antworten. Auch das kostet wertvolle Zeit.
c) oder ob er erst gar nicht den Server fragt, ob die Datei noch aktuell ist, weil er es bereits weiß und die Datei aus seinem Cache anzeigt. Das wäre doch der Idealfall. Aber wie macht man das? Was passiert, wenn sich die Datei auf dem Server doch geändert hat und der Browser merkt es nicht?
Das Ergebnis des Falls c) wird immer ein Kompromiss zwischen Aktualisierungsnotwendigkeit und Geschwindigkeit sein, aber die Konfiguration lohnt sich. Man muss nur wissen, was man tut.
Wir starten mit dem Aktivieren des Apache Moduls „expires“:
a2enmod expiresWer nur eine einzige Website mit dem Apache betreibt, kann die Einstellungen in die „Ladedatei“ des Moduls verlinkt unter
/etc/apache2/mods-enabled/expires.loadstecken (eine expires.conf gibt es aus unerfindlichen Gründen nicht). Wer etwas differenzierter vorgehen möchte, kann die Einstellungen auch in die entsprechenden VirtualHost Abschnitte packen, dann sollte das erneute Laden des Moduls in der ersten Zeile aber ausgeklammert werden:
[code]LoadModule expires_module /usr/lib/apache2/modules/mod_expires.so
ExpiresActive OnExpiresByType image/gif “access plus 1 weeks”
ExpiresByType image/jpeg “access plus 2 hours”
ExpiresByType image/png “access plus 1 weeks”
ExpiresByType text/css “access plus 1 weeks”
ExpiresByType image/x-icon “access plus 1 weeks”
ExpiresByType image/icon “access plus 1 weeks”
ExpiresByType application/javascript “access plus 1 weeks”
ExpiresByType application/x-javascript “access plus 1 weeks”
ExpiresByType text/js “access plus 1 weeks”
[/code]
Zum Schluss das Durchstarten des Apache nicht vergessen:
/etc/init.d/apache2 restartDie hier gewählten Einstellungen geben den unterschiedlichen MIME-Typen unterschiedliche Zeiten mit, nach Ablauf welcher Zeit der Browser überhaupt wieder anfragen soll, ob die Datei noch aktuell ist. Dabei sind Dateitypen, die seltener geändert werden auf längere Zeiten gesetzt, Produktbilder vom Typ JPEG stehen auf immerhin zwei Stunden und sollten daher auch einen längeren Besuch eines Kunden überstehen, ohne erneut geladen zu werden.
Im Firebug sollten jetzt beim Surfen über die Seiten ab der zweiten Seite immer nur die Elemente geladen werden, die der Browser noch nicht kennen kann, z.B. die erzeugte HTML Seite selbst oder das Produktbild oder den Google Tracking Code, der immer auslöst.
Nach zwei Stunden müßten die Produktbilder jeweils einmal neu überprüft werden (304 – not modified)
Wer seinen Produktbestand und das Template so gut wie nie verändert, kann hier noch längere Zeiten eintragen. Gerade die Add-Ons YSlow! und Pagespeed honorieren das mit einer besseren Bewertung. Bitte beachtet, dass der Typ html in der Liste nicht auftaucht und auch nicht auftauchen sollte. Shopware gibt hier ohnehin die Header „Cache-Control“ und „Pragma“ mit Wert „no-cache“ mit und stellt so sicher, dass dynamisch erzeugte Seiten auch dynamisch bleiben.
Das ganze läßt sich auch noch stärker diversifizieren, indem man dem Apache über <location …> bzw. <filematch …> eingrenzt, wo welche Regel für welche Dateien gelten soll.
Ach ja: Das unter b) erwähnte Abprüfen per „If-none-Match “ gilt als veraltet und ist z.B. nach Serverumzügen oder bei Nutzung eines CDN eher hinderlich als nützlich. Im Apache läßt es sich über einen Eintrag in der Config zentral ausschalten:
FileETag noneIst außer einem etwas schlankeren http-Header kein riesiger Gewinn, bringt aber einen Bewertungspunkt bei YSlow!
Moin, deine Artikel sind online. http://www.shopware.de/wiki/Labs_cat_444.html Herzlichen Dank noch einmal dafür Was planst du denn noch so an Artikeln? Dann kann ich da eine kleine Vorschau integrieren… Interessant fände ich auch nochmal die Einrichtung Memcache - ansonsten können wir uns da ja etwas abstimmen! :thumbup:
Bitte hier noch das “Plaintext einsehen” entfernen. http://www.shopware.de/wiki/Tutorialrei … l_603.html Wie bereits per PN geschrieben käme da noch ein bisschen MySQL, Minifying&Sprites, Reduzierung von Aufrufen und Verteilung Requests auf Subdomains hinzu. Bei Memcache hatte ich mich nicht so doll geschlagen, das kannst besser Du machen.
Hallo, um nochmals Ladezeit zu verbessern, haben wir heute ein Plugin veröffentlicht http://store.shopware.de/sonstiges/cssjscompressor Das Plugin kombiniert und minimiert alle CSS- und JS-Dateien. Über Fragen und Feedback freuen wir uns.