Magento ist wohl die PHP Anwendung, der man die schlechteste Performance und den höchsten Verschleiß an Programmierern nachsagt. Das geht so weit das es PHP Programmierer gibt, die sich schon deshalb weigern mit Magento Projekten zu tun zu haben, weil sie sonst noch weitere Magento Projekte bekommen könnten. Auch Aussagen wie "Magento hat schon jeden geschafft" sind keine ungewöhnlichen Aussagen.

Unter Leuten die mit Magento arbeiten gibt es häufig 3 Stadien die in dieser Reihenfolge durchlaufen werden.

1. Magento ist totaler mist. (meist, weil man die Strukturen und Konzepte noch nicht verstanden hat und man teils für scheinbare Kleinigkeiten an mehreren Stellen Anpassungen machen muss)
2. Magento ist total super. (dieser Status beginnt meist mit dem Verstehen der Grundkonzepte hinter Magento. man findet es mit einem mal ganz einfach Dinge über Events und Layout Updates anzupassen und kann auch schon eigene Controller schreiben)
3. Verbrennt diesen Müll doch bitte endlich (Es ist Ernüchterung über die ganzen Möglichkeiten eingetreten, denn es funktioniert grundsätzlich nichts wie erwartet. Zeitschätzungen multiplizieren sich, die Zahl der von Nutzern bemerkten Bugs steigt und von einem auf den anderen Tag hören Dinge auf zu funktionieren, die man Wochen lang nicht angefasst hat.)

Bevor ich mich damit befasse, nehme ich mir aber lieber den Mythos Performance vor.

Zunächst einmal ist Magento ein wirklich großes Projekt das versucht wurde sehr sauber und modular umzusetzen.
Daraus resultiert eine recht hohe Zahl an php Datein.
In der Version 1.7 von Magento sieht das dann so aus:

• ./app/code: 5205 php Datein von denen jede eine Klasse enthält
• ./lib: 2664 php Datein
• ./app/design/ knapp 1000 php basierte template Datein
• zusätzlich noch alle php Datein von zusätzlich installierten Modulen

Wir können also von mindestens 9000 PHP Datein ausgehen.
Das alleine ist eine gute Begründung, wieso Magento auf shared Hosts und kleinen virtuellen Servern recht enttäuschend läuft. Hauptgrund ist dafür aber nicht nur die CPU, sondern auch die performance des Dateisystems und der Tatsache, dass der Autoloader die Dateisystem requests praktisch mit 4 multipliziert. Ursache dafür wiederrum ist, dass Magento an 4 Orten + den ursprünglichen Include Paths nach Klassen sucht. Der andere Punkt ist die Config des OpCode caches, selbst in PHP 5.5 haben wir eine empfohlene Limitierung auf 4000 Datein. Jedem dürfte klar sein, dass man für ein optimal laufendes Magento hier mindestens 10000 eintragen sollte. Und wenn man die OpCache config schon anpasst, sollte man auch darauf achten, dass opcache.enable_file_override aktiviert wird. Das minimiert eben genannte Dateisystem zugriffe während des Autoloadings auf wenige ms und wirkt sich auch positiv auf die fallback funktion von templates aus.

Damit sollte geklärt sein, wieso Magento auf Shared Hosts so schlecht läuft. Die Config ist einfach nicht darauf ausgelegt, derart große Projekte zu unterstützen.

der zum zählen der .php Datein genutze code:

find ./app/code/ -type f -name "*.php" -print | wc -l
find ./lib/ -type f -name "*.php" -print | wc -l

###Weitere blog Beiträge:

Mythen über Magento und Datenbanken

Über die Gründe, wieso Programmierer Magento so wenig leiden können bzw. anfangen es zu hassen, erzähle ich dann in einem anderen Blogpost.