Bekanntlich kann auf kein Speichermedium annähernd so schnell zugegriffen werden wie auf den Arbeitsspeicher, das RAM. Ausreichend verfügbares RAM vorausgesetzt, ist Magentos /var/cache (oder nach Belieben auch das gesamte Verzeichnis /var ) geradezu prädestiniert dafür, in eben diesem gespeichert zu sein.

Genaugenommen kommt statt einer Ramdisk das zeitgemäßere tmpfs (Temporary File System) zum Einsatz. Ein entscheidender Vorteil einer tmpfs-Partition ist, dass die Größe des RAM, die sie belegt, variabel ist: Eine tmpfs-Partition belegt physisch immer nur so viel Arbeitsspeicher, wie sie aufgrund ihrer aktuellen Größe gerade braucht. Sie wächst quasi mit, bis zum Wert, der als erlaubtes Maximum definiert wurde.

Die im Web an vielen Stellen zu findende Syntax funktioniert übrigens nicht, da mit dieser das Device von Magento nicht beschreibbar ist. Man muss es explizit User und Gruppe www-data zuweisen (das bezieht sich auf Debian/GNU, Ubuntu Server und deren Derivate; bei anderen Distributionen entsprechend dem User und der Gruppe, unter welchem bzw. welcher der Webserver läuft). Und zwar so:

mount -t tmpfs -o size=1G,mode=0744,uid=www-data,gid=www-data tmpfs /var/www/ihr-host/var/cache/

In o.g. Beispiel wird der tmpfs-Partition eine maximale Größe von einem Gbyte zugewiesen. Erlaubt sind natürlich auch Werte im Mbyte-Bereich, z.B. 512M oder 800M etc.

Zu bedenken ist, dass Partition und ergo deren Inhalt nach einem Neustart weg sind. Soll die Partition nach einem Neustart automatisch gemountet werden, erreicht man dies durch einen Eintrag in /etc/fstab .

Manuell kann man die Partition bei Bedarf mit

umount tmpfs

unmounten.

Zahlreiche Browser limitieren die Anzahl gleichzeitiger Requests pro Host auf zehn. Gerade bei komplexen CMS oder Shopsystemen, deren Seitenaufrufe eine große Anzahl paralleler Requests auslösen, bedeutet diese Beschränkung einen clientseitigen Flaschenhals.

Diesen beseitigen wir, indem wir die Requests auf verschiedene Hosts verteilen. Im Magento-Backend findet sich hierfür unter “Konfiguration” -> “System” -> “Web” -> “Ungesichert” eine entsprechende Konfigurationsmöglichkeit:

Hier tragen wir nun jeweils vom Basis-Host abweichende Hosts ein:

Zuvor müssen die entsprechenden Hosts natürlich existieren und konfiguriert werden. Am Beispiel von js.host.tld sieht die entsprechende Apache-Konfigurationsdatei so aus:

<VirtualHost *:80>
ServerAdmin webmaster@host.tld

ServerName js.host.tld
DocumentRoot /var/www/host
<Directory /var/www/host/>
Options -Indexes FollowSymLinks MultiViews
AllowOverride None
Order deny,allow
deny from all
</Directory>
<Directory /var/www/host/js/>
Options -Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
Include /etc/apache2/deflate-expires.conf
</Directory>

ErrorLog /var/log/apache2/js.host_error.log
LogLevel warn
CustomLog /var/log/apache2/js.host_access.log combined
</VirtualHost>

Erläuterungen hierzu:

Der erste Directory-Container definiert das Verhalten des Magento-Rootverzeichnisses. Auf selbiges zeigen nämlich auch die zusätzlichen Hosts. Hier sollte zwecks Vermeidung von Duplicate Content unterbunden werden, dass das Magento-Rootverzeichnis über weitere Hosts erreichbar ist:

Order deny,allow
deny from all

Der zweite Directory-Container dagegen erlaubt den Zugriff für das jeweils benötigte Verzeichnis (in diesem Beispiel /js):

Order allow,deny
allow from all

Mit dem nachfolgenden Include-Befehl wird eine .conf-Datei inkludiert, welche die Inhalte aufweist, die eigentlich in der .htaccess-Datei des jeweiligen Verzeichnisses untergebracht sind. Ich habe diese “deflate-expires.conf” benannt, da im Wesentlichen Kompressions- und Expires-Anweisungen darin enthalten sind (und ich dieselbe Datei auch in weitere Hostfiles inkludiere, eine möglichst allgemeine, beschreibende und host-unabhängige Bezeichnung ergo angebracht ist).

Ich selbst arbeite nach Möglichkeit nicht mit .htaccess-Dateien (Direktive “AllowOverride None”). Sofern .htaccess-Dateien Berücksichtigung finden sollen, kann das Inkludieren von Anweisungen entfallen (Direktive “AllowOverride All”).

Analog dazu wird für die weiteren gewünschten Hosts verfahren (media.host.tld, skin.host.tld,…). Bei Bedarf kann für SSL-Requests ebenso verfahren werden, allerdings wird dann für jeden Host ein separates SSL-Zertifikat benötigt (oder alternativ ein Wildcard-Zertifikat, das Subdomains einschließt).

Fazit:

Durch das Verteilen der Requests auf weitere Hosts erreicht man im Handumdrehen eine Verfielfachung der clientseitigen Begrenzung simultan möglicher Requests. Mit Einrichtung und Inbetriebnahme der Hosts js, media und skin können theoretisch statt zehn vierzig Requests parallel durchgeführt werden.