Dies führt auch bei meinen Kunden regelmäßig zu Verwirrungen. Speziell wenn der Kunde selber über ein CMS auf seiner Website Texte eingeben und ändern kann. Zwar wird auf Schulungen immer darauf hingewiesen, dass tunlichst keine manuellen Umbrüche im Absatz genutzt werden sollen, aber wenn das technische Verständnis zur Problematik fehlt, ist das auch schnell wieder vergessen. Der Anwender sieht zunächst mal nur das Ergebnis in seinem Browser und alles scheint in Ordnung.

Hier mal ein paar Screenshots eines einfachen Textes mit font-size: 12px in verschiedenen Browsern und Betriebssystemen (Quelle: Adobe Browserlab).

Übersicht (Achtung: 6.255 x 719 Pixel)

Vergleich IE8 mit IE9

Firefox 3.6 OSX <-> Windows

Gründe für dieses Verhalten

• Verschiedene Verfahren des Textrenderings.
• Unterschiedliche Berücksichtigung von Font-Informationen wie Spacing, Kerning und Hinting.
• Abweichende Interpretation von CSS-Anweisungen.
• Bildschirmauflösung Windows = 96 dpi (dot per Inch = Punkte per Zoll) / Mac = 72 dpi.

Lösungen

Zunächst mal muss jeder Screendesigner und Webdesginer lernen, dass der Browser kein abgeschlossenes Blatt Papier mit einer festen Größe ist. Eine normale Website hat in der Regel mehr oder weniger festgelegte Spaltenbreiten und ist in der Höhe flexibel. Der Webdesigner kann nur erahnen, wieviel Text eine bestimmte Textbox später in der Praxis haben wird. Hier werden die Kunden meist sehr Kreativ. Das Weblayout muss also für Textrahmen flexibel gestaltet sein.

Bedingter Trennstrich

Wie man an den Screenshots schön erkennen kann, machen manuelle Umbrüche auch keinen Sinn. Allerdings gibt es auch schon seit den Anfangstagen des WWW den bedingten Trennstrich &shy; (= soft hyphen = bedingter Trennstrich). Damit kann man speziell bei sehr langen Wörtern dem Browser einen Vorschlag zur Trennung machen. Steht das Wort mitten im Fließtext passiert gar nichts, das Zeichen ist nicht sichtbar. Steht das Wort am Ende eines Textrahmens, erfolgt an der Sollbruchstelle durch den Browser ein Umbruch und ein Trennstrich wird eingefügt.

CSS-Angaben im Stylesheet

Auch bei der Angabe der Schriftgröße im Stylesheet kann man schon einiges falsch machen. Zu diesem Thema könnte man ganze Bücher füllen. Hier ein Verweis zur Einführung: Das Windows/Mac font-size-Problem. In der Praxis benutze ich für kleine Webprojekte meistens die schnelle Variante der Angabe in Pixeln. Der oft angemerkte Nachteil bei der Skalierung durch den Anwender ist nicht mehr gültig, da alle modernen Browser auch Pixel-Angaben richtig skalieren können. Bei größeren Projekten Arbeite ich gerne mit prozentualen Größenangaben. Hierzu werden vorher per CSS alle Angaben auf einen einheitlichen Wert von 13px gebracht. Dann kann man zum Beispiel über font-size: 116% eine Schriftgröße von 15px erzielen. Weitere Infos dazu gibt es zum Beispiel bei YUI 2: Fonts CSS.

Textersetzung durch Grafiken/Flash

Und wenn man sich dann doch mal auf eine 100% korrekte Darstellung eines Textrahmens verlassen muss? Auch dazu gibt es einige Möglichkeiten. Letztlich wird der Text dann als Grafik oder Flash in die Website eingebaut. Hierbei sollte man aber darauf achten, dass der dargestellte Text weiterhin als solcher im Quelltext der Website steht, damit Google & Co. glücklich sind. Die Technik dazu nennt sich Image-Replacement und eine Übersicht der gängigen Umsetzungen findet man zum Beispiel bei Jens Meiert oder auch bei css-tricks.com. Das sollte aber eine absolute Ausnahme sein, wenn es wirklich nicht mehr anders geht.

Übersicht / Checkliste

• PHP
  • APC (Bytecode-Cache) oder Memcached (Memory Object Caching)
• MySQL
  • Query Caching aktivieren
  • Per tuning-primer.sh Shellscript prüfen und optimieren
• Apache
  • MPM-Prefork Tuning
  • KeepAlive aktivieren, HostNameLookups deaktivieren
  • mod_deflate
  • mod_expires
  • .htaccess Einträge in vhost Konfiguration
• Dateisystem (Linux)
  • tmpfs (Ramdisk)
• Magento
  • Sessions in der Datenbank speichern
  • Zusammenfassung der Javascript und CSS-Dateien durch die Extension Fooman Speedster
  • Image Sprites verwenden
  • Magento Cache aktivieren
  • Content Delivery Network für statische Dateien und Produktbilder

Benchmarking

Sowohl die Ausgangsbasis einer Magento-Installation, als auch jede technische Veränderung am System sollte per Benchmark geprüft und protokoliert werden. Dies kann zum Beispiel auf dem Server direkt über das Apache HTTP server benchmarking tool gemacht werden. Wenn das Gesamtpaket des Webservers optimiert wurde, sollten noch die Ladezeiten im Browser über Yahoo! YSlow for Firebug geprüft werden.

Zunächst die notwendigen Schritte um ein neue Maschine innerhalb von Amazon AWS zu installieren.

1. AWS-Account anlegen: http://www.amazon.com/gp/aws/registration/registration-form.html
2. Unter Security Credentials einen Access Key anlegen und aktivieren: http://aws-portal.amazon.com/gp/aws/developer/account/index.html?action=access-key
3. Ebenfalls im Bereich Security Credentials ein X.509 Zertifikat erstellen und den privaten Schlüssel (pk-.pem) und das Zertifikat (cert-.pem) herunterladen. Unter Linux oder Mac speichert man die Zertifikate im Benutzer-Verzeichnis ~/.ssh. Unter Windows benutzt man am besten Putty und bindet dort die Zertifikate  ein.
4. Bei der AWS Management Console anmelden: https://console.aws.amazon.com/
5. Zum Bereich Amazon EC2 wechseln.
   
6. Eine neue Amazon EC2 instance anlegen: Region auf „EU West“ umstellen und auf Launch Instance klicken. Danach kann man eine Amazon Machine Image (AMI) auswählen, also das Betriebssystem des virtuellen Servers. Um den Sever kostenlos nutzen zu können muss man darauf achten, das bei Instance Type „Micro“ eingestellt wird. Die von Amazon vorkonfigurierte Maschine „Ubuntu 10.04 LTS“ geht zum Beispiel nicht. Ich entscheide mich aus der Quick Start Liste für „SUSE Linux Enterprise Server 11 64-bit“ (AMI Id: ami-6e57621a), um ein LAMP mit Apache 2.2, MySQL 5.0 und PHP 5.3 zu erstellen. Achtung: Bei dieser Instanz fallen Kosten an und zwar $0,035 pro Stunde. AWS macht einen Unterschied zwischen Linux/UNIX und SUSE Linux Instanzen. Das ist mir leider auch erst bei der ersten Rechnung aufgefallen. Wer hier also wirklich nichts zahlen will, wählt lieber eine der Basic-Instanzen.
   
7. Die folgenden Einstellungsdialoge als Screenshot:
    

   

   

   

8. Im Bereich Security Group müssen nun noch Freigaben für die Ports 22 und 80 erstellt werden.
   

Die virtuelle Maschine ist nun konfiguriert und man kann man sich bereits mit dem Server über die Public DNS per SSH verbinden. Hierzu benötigt man die Schlüsseldatei aus Schritt 7:

ssh -i pfad-zum-pk/ec2-keypair root@ec2-xx-xxx-xx-xx.eu-west-1.compute.amazonaws.com

Nun geht es an die SuSE-Konfiguration. Obwohl die Beschreibung der AMI etwas anderes behauptet hat, muss man zunächst alle notwendigen LAMP-Komponenten installieren (http://developer.amazonwebservices.com/connect/thread.jspa?threadID=53482&tstart=0).

zypper in apache2-mod_php5 mysql
chkconfig apache2 on
chkconfig mysql on
service mysql start
service apache2 start

Damit Apache .htaccess Dateien verwendet, muss in der Datei /etc/apache2/default-server.conf der Bereich „Directory“ der Wert von AllowOverride auf All angepasst werden:

<Directory "/srv/www/htdocs">
# Possible values for the Options directive are "None", "All",
# or any combination of:
#   Indexes Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI MultiViews
#
# Note that "MultiViews" must be named *explicitly* --- "Options All"
# doesn't give it to you.
#
# The Options directive is both complicated and important.  Please see
# http://httpd.apache.org/docs-2.2/mod/core.html#options
# for more information.
Options None
# AllowOverride controls what directives may be placed in .htaccess files.
# It can be "All", "None", or any combination of the keywords:
#   Options FileInfo AuthConfig Limit
AllowOverride All
# Controls who can get stuff from this server.
Order allow,deny
Allow from all
</Directory>

Für Magento müssen noch fehlende Pakete installiert und mod_rewrite aktiviert werden:

zypper in php5-mysql
zypper in php5-mcrypt
zypper in php5-curl
zypper in php5-gd
a2enmod rewrite
rcapache2 restart

Der Webserver ist nun tatsächlich einsatzbereit. Magento wird im Standardverzeichnis /srv/www/htdocs/ installiert. Also Los:

cd /srv/www/htdocs/
wget http://www.magentocommerce.com/downloads/assets/1.4.1.1/magento-1.4.1.1.tar.gz
wget http://www.magentocommerce.com/downloads/assets/1.2.0/magento-sample-data-1.2.0.tar.gz
tar -zxf magento-1.4.1.1.tar.gz
tar -zxf magento-sample-data-1.2.0.tar.gz
mv magento-sample-data-1.2.0/media/* magento/media/
mv magento-sample-data-1.2.0/magento_sample_data_for_1.2.0.sql magento/data.sql
mv magento/* magento/.htaccess .
chmod -R o+w media
mysqladmin -u root create magento
mysql -u root magento < data.sql
./pear mage-setup .
./pear install magento-core/Mage_All_Latest-stable
chmod o+w var var/.htaccess app/etc
rm -rf downloader/pearlib/cache/* downloader/pearlib/download/*
rm -rf magento/ magento-sample-data-1.2.0/
rm -rf magento-1.4.1.1.tar.gz magento-sample-data-1.2.0.tar.gz data.sql

Die weitere Installation von Magento erfolgt dann über den normalen Webinstaller. Der erste Eindruck ist für den gewählten Servertyp (Micro) mit 613 MB RAM und 1 CPU Core und ohne Server-Tuning erstaunlich gut. Der Benchmarktest mit ab2 liefert 1,64 Requests pro Sekunde. Kein Weltrekord aber als Ausgangsbasis schon mal nicht schlecht.

ab2 -c 2 -n20 http://46.51.176.105/coalesce-functioning-on-impatience-t-shirt.html: 1.64 Requests per second

Ein weiterer Test mit einem anderen Instanzen-Typ (Large) ergibt 2.76 Requests per second. Mit 7,5 GB Arbeitsspeicher und 4 EC2-Recheneinheiten gibt es nun genügend Reserven, um mit den üblichen Performance-Tunings Magento weiterzubringen. Nach der Installation von APC ergibt der Benchmark 4.93 Requests per second. Wieder zurück zu Micro und mit APC leistet der Server 2.91 Requests per second.

Fazit: Die Installation eines virtuellen Servers in der Amazon Cloud verläuft einfach. Natürlich muss man sich mit den Begriffen und Techniken erst mal beschäftigen und nach einem Tag hat man sicher noch nicht alle Möglichkeiten ergründet. Die eigentliche Konfiguration des LAMPs und der Installation der Anwendungen (hier Magento) unterscheidet sich in keinster Weise von dem vorgehen auf einem Root- oder Managed-Server.

Mit der Performance bin ich noch nicht ganz zufrieden, aber für weitere Optimierung bietet die Cloud noch viele Schrauben zum Drehen. Die Hardware-Frage muss nun nicht mehr zu Beginn eines Projektes beantwortet werden, sondern kann innerhalb von Minuten dem aktuellen Bedarf angepasst werden.

<?php echo Mage::helper('checkout/cart')->getItemsQty() ?>
<?php echo Mage::helper('checkout/cart')->getItemsCount() ?>

Formatierte Gesamtsumme:

<?php echo $this->helper('checkout')->formatPrice(Mage::getSingleton('checkout/cart')->getQuote()->getGrandTotal()) ?>

Beispiel:

<?php printf('Ihr Warenkorb: %d Artikel zu %s', Mage::helper('checkout/cart')->getItemsQty(), $this->helper('checkout')->formatPrice(Mage::getSingleton('checkout/cart')->getQuote()->getGrandTotal())) ?>

Der erste Teil hat das Vorgehen bei einer neuen TYPO3-Installation beschrieben. In der Praxis kommt es aber auch oft vor, dass man ein vorhandenes System vorfindet, bei dem keine durchgängige UTF-8 Kodierung besteht. Meist ist zwar TYPO3 mit forceCharset und die MySQL-Datenbank korrekt mit UTF-8 Zeichensatz konfiguriert, die Datenbank-Verbindung zwischen TYPO3 und der Datenbank wird aber manchmal vergessen. In der der Standardeinstellung und somit auch bei den meisten Hostern, erfolgt die Verbindung zwischen PHP und der MySQL-Datenbank über latin1. Im Ergebnis landen dann doppelt UTF-8-kodierte Daten in der Datenbank.

Im Betrieb fällt es nicht auf, da alle Sonderzeichen wie z.B. Umlaute korrekt dargestellt werden. Erst bei einem Umzug der Datenbank oder wenn man die Daten außerhalb von TYPO3 verwenden möchte stellt man fest, das etwas nicht stimmt.

Die Problematik und weitere Szenarien werden ausgiebig im TYPO3 Kochbuch in Kapitel 2.10 “Den Zeichensatz einer bestehenden TYPO3- Installation prüfen und auf UTF-8 umstellen“ behandelt. Die wichtigsten Schritte gibt es hier. Zunächst müssen Informationen über das bestehende System gesammelt werden.

1. Zeichensatz der Datenbank

SELECT distinct(character_set_name) FROM INFORMATION_SCHEMA.COLUMNS WHERE table_schema = 'datenbank_name' AND NOT character_set_name IS NULL

2. Zeichensatzhandhabung der MySQL-Verbindung

Wurde $TYPO3_CONF_VARS['SYS']['setDBinit'] = ‘SET NAMES utf8′; in localconf.php gesetzt? Dann erfolgt die Kommunikation der TYPO3-DB-API mit dem MySQL Server über UTF-8. Ansonsten erfolgt die Verbindung im MySQL-Modul von PHP standardmäßig über latin1. Im Zweifel müssen die Variablen character_set_client, character_set_connection und character_set_result über eine TYPO3-DB-API Abfrage geprüft werden (SHOW VARIABLES LIKE ‘character_set_%’).

3. Zeichensatzkonfiguration von TYPO3

Wert von forceCharset prüfen. Wenn dieser nicht gesetzt ist, benutzt TYPO3 standardmäßig den Zeichensatz ISO 8859-1 (Latin 1).

Ergebnis

Zu 5.: UTF-8-kodierten Daten in der Latin1-Datenbank

mysqldump -u USER -p --default-character-set=latin1 datenbank_name > datenbank_name.sql

Zu 6.: Doppelt UTF-8-kodierten Daten

mysqldump -u USER -p --default-character-set=latin1 datenbank_name > datenbank_name.sql

In allen anderen Fällen:

mysqldump -u USER -p datenbank_name > datenbank_name.sql

Im Ergebnis hat man nun immer einen Dump mit korrekt kodierten UTF-8-Daten. Aber: mysqldump speichert den beim Dump verwendeten Zeichensatz, ebenso wie den Zeichensatz der Datenbank, innerhalb der Dump-Datei mit ab. Aus diesem Grund müssen innerhalb des Dumps alle Vorkommen von latin1 nach utf8  (innerhalb von SET NAMES latin1 oder DEFAULT Max. CHARSET latin1) abgeändert werden.

Nun wird TYPO3 für UTF-8 eingerichtet (siehe Teil 1) und danach der Dump wieder eingespielt. Dazu löscht man die vorhandene Datenbank (DROP DATABASE datanbank_name;) und lädt den Dump über:

mysql -u USER -p datenbank_name < datenbank_name.sql

Was man jetzt noch prüfen sollte: Sind die HTML-Templates auch UTF-8 Kodiert? Und natürlich wie immer das ganze System gründlich testen.

Wichtig ist hier vor allem die richtige Reihenfolge, damit später nicht zwei verschiedene Zeichensätze in der Datenbank landen. Ein zweiter Artikel zeigt, wie man ein vorhandenes TYPO3-Projekt umstellt.

1. TYPO3 Basisversion installieren (Source+Dummy)

2. Datenbank erstellen

CREATE DATABASE datenbank_name DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;

Die Kollation „utf8_general_ci“ wird empfohlen. „utf8_unicode_ci“ ist zwar genauer, aber langsamer und unterscheidet sich im Deutschen nur bei SELECT-Abfragen, bei denen im Datensatz ein „ß“ vorkommt. Hier würde im einen Fall nach einem einfachen, im anderen Fall nach einem doppelten „s“ sortiert.

3. localconf.php anpassen

$TYPO3_CONF_VARS['BE']['forceCharset'] = 'utf-8';
$TYPO3_CONF_VARS['SYS']['setDBinit'] = 'SET NAMES utf8';

Diese Einstellungen müssen unbedingt vor dem Import der TYPO3-Tabellen gemacht werden. Dadurch verwendet TYPO3 UTF-8 als Zeichenkodierung und auch die Verbindung zur MySQL-Datenbank erfolgt über UTF-8.

Durch setDBinit ist man unabhängig von den Einstellungen aus my.conf. Auch bei einem Umzug auf einen anderen Server bleibt die Datenbankverbindung konsistent.

Erst jetzt darf die letzte Schritt im TYPO3 Install Tool zum Import der Datenbank durchgeführt werden.

4. Test der Installation

Im Backend einen Admin-Benutzer mit Umlauten anlegen (zum Beispiel Müller). Sowohl im Backend als auch in phpMyAdmin muss in der Spalte realName ein „ü“ angezeigt werden. Wird irgendwo das „ü“ als „ü“ angezeigt, ist leider etwas schief gelaufen.

5. Webserver

Der Browser erkennt die Kodierung der Website zunächst am Content-Type-Feld im HTTP-Header. Nur wenn der HTTP-Header keine Angaben zur Kodierung enthält, wird der Content-Type Meta-Tag im HTML-Code ausgewertet. TYPO3 setzt aufgrund des forceCharset ebenfalls den richtigen HTTP-Header, auch wenn der Webserver eventuell noch auf charset=ISO-8859-1 eingestellt ist.

6. Browserausgabe prüfen

Durch die forceCharset Angabe werden bereits die Inhalte der Website in UTF-8 ausgegeben. Die TypoScript Einstellungen für config.metaCharset und config.renderCharset sollten überprüft und gegebenefalls entfernt werden.

7. Templates

Alle HTML-Templates sollten ebenfalls UTF-8 kodiert abgespeichert werden, damit darin enthaltene Sonderzeichen wie Umlaute usw. korrekt dargestellt werden.

Wie oft eine Bestellung durchgeführt wurde, kann man im Backend von Magento erfahren. Dafür braucht man keine Google Analytics. Interessanter ist die Frage, wieviele Bestellungen nicht abgeschlossen wurden und an welcher Stelle die Besucher den Einkauf abbrechen.

Um das zu Erfahren definiert man einen Trichter in Google Analytics. Auf der Seite „Websiteprofile“ auf Bearbeiten klicken und dann im Bereich „Ziele“ über Ziel hinzufügen einen neuen Trichter anlegen. Also eine Startseite, eine Endseite und alle Seiten die dazwischen liegen. Die Startseite für den Checkout ist /checkout/onepage und die Zielseite ist /checkout/onepage/success/. Diese beiden Adressen im Trichter definiert ergeben schon mal zwei Zahlen. Wieviele haben den Checkout gestartet und wieviele sind am Ende übrig geblieben.

Was fehlt sind die Seiten dazwischen. Leider kann man die Zwischenseiten wie Versandart, Zahlungsart usw. nicht so einfach messen. Magento ruft diese Seiten über Ajax auf und somit gehen die Aufrufe an Google Analytics vorbei. Es gibt die Extension Fooman Google Analytics Plus, die alle Ajax-Requests an Google Analytics sendet. Mir geht diese Extension etwas zu weit und deshalb benutze ich eine angepasste opcheckout.js zu diesem Zweck.

opcheckout.js vorher:

gotoSection: function(section)
{
section = $('opc-'+section);
section.addClassName('allow');
this.accordion.openSection(section);
},

opcheckout.js nachher:

gotoSection: function(section)
{
try {
pageTracker._trackPageview('/checkout/onepage/' + section + '/');
} catch(err) {}
section = $('opc-'+section);
section.addClassName('allow');
this.accordion.openSection(section);
},

Nach dieser Anpassung werden dann auch die Zwichenseiten in der Trichteranalyse abgebildet:

Zielname: Einkauf
Aktives Ziel: Ein
Zieltyp: URL-Ziel
Keyword-Optionen: Genau passend
Ziel-URL: /checkout/onepage/success/

Schritte:
/checkout/onepage/ -> Start Kassenprozess | Erforderlicher Schritt = ja
/checkout/onepage/billing/ -> Rechnungsadresse
/checkout/onepage/shipping/ -> Versandadresse
/checkout/onepage/shipping_method/ -> Versandart
/checkout/onepage/payment/ -> Zahlungsart
/checkout/onepage/review/ -> Zusammenfassung

Man kann die Bestellung zwar bearbeiten, aber mir gefällt die durch einen Stornovorgang anfallende zusätzliche Bestellung nicht. Wenn man sich etwas mit SQL auskennt, kann man die Adresse auch schnell in der Datenbank korrigieren. Die folgenden SQL-Befehle gelten für Magento 1.3.x und befördern die entsprechenden Zeilen zurück.

SELECT customer_email FROM sales_flat_quote WHERE customer_email = ‘falsche@adresse.de’;
SELECT email FROM sales_flat_quote WHERE email = ‘falsche@adresse.de’;
SELECT sales_order_varchar FROM sales_order_varchar WHERE sales_order_varchar = ‘falsche@adresse.de’;

Rückblick

Der Einsatz eines aktuellen Rootservers sowie die Installation von APC und Konfiguration von MySQL ergaben zuletzt eine Performance von 6,74 Requests pro Sekunde auf eine Artikelseite. Weitere versuchen mit TMPFS im Bereich des Cache-Verzeichnisses von Magento ergaben keine Verbesserungen.

Update

Vor dem Update von 1.2.1.2 auf 1.3.2.1 habe ich noch mal die aktuelle Performance gemessen. Da der Webserver inzwischen nicht mehr nur alleine für den Vitalityshop zuständig ist, ist die Leistung wie erwartet etwas geringer geworden.

ab2 -c 5 -n 100 http://www.vitalityshop.de/blue-lagoon-mineral-foaming-cleanser.html

Concurrency Level:      5

Time taken for tests:   15.755 seconds

Complete requests:      100

Failed requests:        0

Write errors:           0

Total transferred:      2704100 bytes

HTML transferred:       2659400 bytes

Requests per second:    6.35 [#/sec] (mean)

Time per request:       787.747 [ms] (mean)

Time per request:       157.549 [ms] (mean, across all concurrent requests)

Transfer rate:          167.61 [Kbytes/sec] received

Concurrency Level:      5
Time taken for tests:   15.755 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      2704100 bytes
HTML transferred:       2659400 bytes
Requests per second:    6.35 [#/sec] (mean)
Time per request:       787.747 [ms] (mean)
Time per request:       157.549 [ms] (mean, across all concurrent requests)
Transfer rate:          167.61 [Kbytes/sec] received

Der neue Startwert für Vergleiche ist also 6,35 Requests pro Sekunde. Nach dem Update auf die Version 1.2.3.1 und Neuerstellung sämtlicher Caches und Indexe ergab die neue Messung 7.80 Requestst pro Sekunde.

Wow, da bin ich doch tatsächlich beeindruckt. In den Releasenotes stand zwar etwas von Perfomance-Steigerung. Aber das steht da ja eigentlich immer. Das es aber 23% werden, das hatte ich nicht erwartet. Glückwunsch Varien!

Cache Layered Navigation

Es gibt in der Cache-Verwaltung einen Schalter um Caching für Layered Navigation zu aktivieren. Die Funktion ist noch Beta und sollte zunächst gründlich getestet werden, bevor man sie bei seinem Shop einsetzt. Ein kurzer Test ergab bei meinem Shop keine Änderung. Laut Beschreibung soll das aber auch nur für umfangreiche Kataloge nützlich sein. Ich habe das wieder deaktiviert.

Minify und Fooman Speedster

Minify ist ein PHP-Script um die Anzahl und Menge der Daten einer Seite zur reduzieren, die vom Webserver zum Browser geschickt werden müssen. Das wird durch Zusamenfassung, Komprimierung und speziellen HTTP-Headern erreicht. Als Ergebnis sollte eine komplette Seite im Browser schneller geladen werden.

Minify ist zwar ein Serverscript, die Performance-Steigerung ergibt sich hier aber nicht durch eine schnellere Seitenerstellung auf dem Server, sondern durch kürzere Übertragung der Daten zwischen Webserver und Browser. Für Magento gibt es die Extension Fooman Speedster die Minify einsetzt.

Um die Wirkung des Scripts prüfen zu können muss die Messung also im Browser stattfinden. Ich nehme dazu YSlow. Hier zunächst die Ergebnisse ohne Fooman Speedster:

Man sieht hier sehr deutlich das der eigentliche HTML-Anteil mit 26,7 KByte im Vergleich zu den anderen Bereichen sehr klein ist. Die JavaScript- und CSS-Dateien belegen zusammen 375,2 KByte von insgesamt 459.0 KByte für den kompletten Request. Dieses Packet muss für jeden neuen Besucher zunächst mal zum Browser übertragen werden. Nach dem Erstkontakt sollte dann (hoffentlich) das Caching des Browsers greifen und es wird nur noch der HTML-Teil der Seiten geladen. In diesem Beispiel also die 26,7 KByte für den HTML-Teil. Es werden aber trotzdem noch bei jedem Request 31 Anfragen zum Server übertragen.

Mit Fooman Speedster zeigt sich dann folgenden Bild:

Die gesamte Übertragungsgröße für die erste Seite  ist von 459,0 KByte auf 170,5 KByte geschrumpft. Bei der gecachten Seite sind nun 7 Requests pro Seite weniger notwendig. Und die Generierung der Seiten auf dem Server dauert auch nicht länger. Ich kann den Einsatz der Extension also nur empfehlen. Es ist nach der Installation lediglich ein Eintrag in der .htaccess vorzunehmen und das Verzeichnis var/minifycache muss Schreibrechte haben.

Fazit

Mit der Version 1.3 von Magento ist Varien ein großer Performance-Sprung gelungen. Bei meinem Shop brachte das Update eine 23% Steigerung im Vergleich zu 1.2.

Mit der einfach zu installierenden Extension Fooman Speedster kann man die Dauer zur Anzeige der ersten Seite für Neukunden deutlich verkürzen. Und schließlich ist der erste Eindruck ja sehr wichtig.

Wie immer würde ich mich über Feedback freuen und zwar nicht nur per E-Mail sondern auch direkt hier im Block

Wenn man Projekte aus verschiedenen Versionen pflegen muss, kann man mit der Pear-Installation nicht mehr arbeiten, da hier immer nur eine Version möglich ist. Ständiges deinstallieren und neu installieren finde ich auch keine gute Alternative. Ich habe mich dazu entschlossen, jedes Projekt fest mit seiner Symfony Library zu verknüpfen.

Der an vielen Stellen dafür vorgeschlagene optimale Platz dafür ist im lib/vendor Verzeichnis.

Nun stellt sich natürlich die Frage der Updates. Entweder lädt man jedes mal das neue Archiv herunter und tauscht es bei allen Projekten komplett aus oder man lässt Subversion die Arbeit für einen machen. Hierbei hat man zusätzlich noch den Vorteil das man Updates noch vor einem offiziellen Release bekommt.

Die nun folgende Anleitung zur Erstellung neuer Projekte bezieht sich auf Symfony 1.2 sowie Subversion und wurde auf meinem MacBook Pro durchgeführt. Es sollte so oder so ähnlich aber auch unter Linux funktionieren.

1.  Repository anlegen

Um das Leben einfacher zu machen setze ich zunächst 2 Umgebungsvariablen. $SVNREP_DIR  bezieht sich auf das Verzeichnis in dem das Repository erstellt werden soll. $PROJECT_NAME hat mehrere Funktionen. Zunächst mal ist es der Projektname unter Symfony. Gleichzeitig aber auch der Verzeichnisname für die Arbeitskopie (Working Copy) und der Name der MySql-Datenbank. Wer das anders habe möchte muss an den entsprechenden Stellen etwas aufpassen.

$ SVNREP_DIR=Users/freeze/svn/symfony_csv
$ PROJECT_NAME=symfony_csv
$ svnadmin create ~/svn/$PROJECT_NAME
$ svn mkdir -m „Standard csv structure“ file:///$SVNREP_DIR/trunk file:///$SVNREP_DIR/branches file:///$SVNREP_DIR/tags
$ svn mkdir -m „Create folder for Symfony“ file:///$SVNREP_DIR/trunk/lib file:///$SVNREP_DIR/trunk/lib/vendor~/svn/$PROJECT_NAME

2. Checkout

Nun wechselt man in das Verzeichnis in dem man seine Projekte verwaltet. Bei mir ist das im Userverzeichnis unter Sites.

$ cd ~/Sites
$ svn checkout file:///$SVNREP_DIR/trunk $PROJECT_NAME
$ cd $PROJECT_NAME

3. Symfony vorbereiten

Symfony wird als externe Referenz in lib/vendor konfiguriert und danach installiert.

$ svn propset svn:externals „symfony http://svn.symfony-project.com/branches/1.2″ lib/vendor
$ svn commit -m „External link to Symfony“
$ svn update

Die aktuellste Version aus dem Branch von Symfony ist nun installiert und man kann mit der Initialisierung des Projektes weitermachen.

$ lib/vendor/symfony/data/bin/symfony generate:project $PROJECT_NAME

Damit das Projekt portabel bleibt sollte noch der Pfad innerhalb von config/ProjectConfiguration.class.php geändert werden:

$ require_once dirname(__FILE__).’/../lib/vendor/symfony/lib/autoload/sfCoreAutoload.class.php’;

Ich lege noch einen symbolischen Link für das web/sf Verzeichnis an, da ich den Apache an dieser Stelle nicht konfigurieren möchte. Das ist aber sicher Geschmacksache.

$ ln -s ../lib/vendor/symfony/data/web/sf/ web/sf

Nun folgen Optimierungen für Subversion. Ins Repository gehören nur Dateien rein die veränderbar sind und nicht etwa automatisch generiert werden. Zu Letzteren gehören sicher die Daten in den Verzeichnissen cache und log, aber auch noch weitere aus lib wie zum Beispiel die Propel-Base Klassen. Die folgenden Einstellungen beziehen sich nur auf Propel.

$ rm -rf cache/*

$ rm -rf log/*
$ svn status | grep ^? | sed „s/? *//“ | xargs svn add
$ svn mkdir data/sql lib/model lib/model/om lib/model/map lib/filter lib/filter/base lib/form lib/form/base lib/task lib/widget
$ svn propset svn:ignore „*“ log
$ svn propset svn:ignore „*“ cache
$ svn propset svn:ignore „*schema-transformed.xml“ config
$ svn propset svn:ignore „lib.model.schema.sql
plugins.*.sql
sqldb.map“ data/sql

$ svn propset svn:ignore „*“ lib/model/om

$ svn propset svn:ignore „*“ lib/model/map

$ svn propset svn:ignore „*“ lib/filter/base

$ svn propset svn:ignore „*“ lib/form/base

$ svn commit -m „Project initialized“

4. Datenbank und Propel-Setup

Bei Bedarf kann man nun die Datenbank vorbereiten. Die Konfiguration von config/schema.yml habe ich hier ausgelassen.

$ ./symfony configure:database „mysql:host=localhost;dbname=$PROJECT_NAME“ user password
$ ./symfony propel:build-filters
$ ./symfony propel:build-forms

$ ./symfony propel:build-model
$ svn commit -m „Propel initialized“

5.  Applikation erstellen

Und zuletzt wird dann die eigentliche Applikation erstellt und noch mal alle neue Verzeichnisse dem Repository bekannt gemacht.

$ ./symfony generate:app –escaping-strategy=on –csrf-secret=Top$ecret frontend
$ svn status | grep ^? | sed „s/? *//“ | xargs svn add
$ svn commit -m „Generate app frontend“

Ergebnis

Am Ende hat man nun ein neues Symfony Projekt unter CVS-Kontrolle. Ein Update der Library kann man mittels svn update lib/vendor durchführen.