TYPO3 CMS

PHP-Serverkonfigurationen im Performancetest

caticonslite_bm_alt

Ziel dieses Vergleichs war es, die performantesten PHP-Konfigurationen für Drupal, TYPO3 und WordPress festzustellen und daraus auf die im Allgemeineinsatz performanteste Konfiguration zu schließen. Getestet wurden die Standardinstallationspakete Drupal 7.16,  TYPO3 4.7 Government Package und WordPress 3.4.2 mit Apache Bench für einen Zeitraum von je 30 Sekunden (z.B. „ab -kc 250 -t 30 http://127.0.0.1/drupal/“). Um möglichst faire Bedingungen zu schaffen wurden die involvierten Software-Komponenten vor jedem Test neu gestartet (z.B. „/etc/init.d/nginx restart && /etc/init.d/php5-fpm restart“). Der Testinstanz waren vier Kerne eines E5649-Xeon-Prozessors, 16 GB RAM und zwei SATA-Festplatten im Hardware-RAID 1-Verbund exklusiv zugewiesen. Als Software wurden die Komponenten in ihrer Standardkonfiguration aus dem Debian Wheezy-Repository eingesetzt.

Folgende Konfigurationen wurden getestet:

  • apache2-mpm-prefork + libapache2-mod-fcgid
  • apache2-mpm-prefork + libapache2-mod-fcgid + php-apc
  • apache2-mpm-prefork + libapache2-mod-php5
  • apache2-mpm-prefork + libapache2-mod-php5 + php-apc
  • apache2-mpm-prefork + libapache2-mod-suphp
  • apache2-mpm-prefork + libapache2-mod-suphp + php-apc
  • apache2-mpm-worker + libapache2-mod-fcgid
  • apache2-mpm-worker + libapache2-mod-fcgid + php-apc
  • apache2-mpm-worker + libapache2-mod-suphp
  • apache2-mpm-worker + libapache2-mod-suphp + php-apc
  • nginx + php5-fpm
  • nginx + php5-fpm + php-apc

Die performantesten Konfigurationen für Drupal:

  1. 152,94 Requests/s, 250 Concurrency: apache2-mpm-prefork + libapache2-mod-fcgid + php-apc
  2. 147,12 Requests/s, 250 Concurrency: apache2-mpm-worker + libapache2-mod-fcgid + php-apc
  3. 146,68 Requests/s, 100 Concurrency: nginx + php5-fpm + php-apc
  4. 145,83 Requests/s, 50 Concurrency: apache2-mpm-prefork + libapache2-mod-php5 + php-apc
  5. 132,43 Requests/s, 50 Concurrency: apache2-mpm-worker + libapache2-mod-fcgid + php-apc
  6. 130,92 Requests/s, 250 Concurrency: apache2-mpm-prefork + libapache2-mod-php5 + php-apc
  7. 128,88 Requests/s, 50 Concurrency: apache2-mpm-prefork + libapache2-mod-fcgid + php-apc

Die performantesten Konfigurationen für TYPO3:

  1. 180,32 Requests/s, 50 Concurrency: apache2-mpm-prefork + libapache2-mod-php5 + php-apc
  2. 179,99 Requests/s, 250 Concurrency: apache2-mpm-worker + libapache2-mod-fcgid + php-apc
  3. 173,87 Requests/s, 250 Concurrency: apache2-mpm-prefork + libapache2-mod-php5 + php-apc
  4. 166,69 Requests/s, 50 Concurrency: apache2-mpm-worker + libapache2-mod-fcgid + php-apc
  5. 166,03 Requests/s, 250 Concurrency: apache2-mpm-prefork + libapache2-mod-fcgid + php-apc
  6. 163,55 Requests/s, 50 Concurrency: apache2-mpm-prefork + libapache2-mod-fcgid + php-apc
  7. 111,03 Requests/s, 100 Concurrency: nginx + php5-fpm + php-apc

Die performantesten Konfigurationen für WordPress:

  1. 57,75 Requests/s, 100 Concurrency: nginx + php5-fpm + php-apc
  2. 55,97 Requests/s, 250 Concurrency:  apache2-mpm-prefork + libapache2-mod-fcgid + php-apc
  3. 52,21 Requests/s, 50 Concurrency: apache2-mpm-worker + libapache2-mod-fcgid + php-apc
  4. 49,93 Requests/s, 50 Concurrency: apache2-mpm-prefork + libapache2-mod-fcgid + php-apc
  5. 48,99 Requests/s, 250 Concurrency: apache2-mpm-worker + libapache2-mod-fcgid + php-apc
  6. 48,09 Requests/s, 50 Concurrency: apache2-mpm-prefork + libapache2-mod-php5 + php-apc
  7. 46,7 Requests/s, 250 Concurrency: apache2-mpm-prefork + libapache2-mod-php5 + php-apc

Download aller Apache Bench-Ergebnisse und der Excel-Auswertung

Fazit:

Dass libapache2-mod-suphp im Vergleich zu den anderen Testkandidaten nicht gut abschneiden und APC die Performance enorm steigern wird, war bereits vor dem Test klar. Enttäuschend war in jedem Fall die Leistung von WordPress, welche auf fehlende Cachingmechanismen im Core zurückzuführen ist. Im allgemeinen Vergleich zeigte besonders libapache2-mod-fcgid bei hohen (250 Concurrency) und moderaten (50 Concurrency) Zugriffszahlen eine gute Performance. Als reiner Webserver mag nginx zwar schneller als Apache sein, im Zusammenspiel mit PHP konnte sich nginx gegen Apache aber nicht durchsetzen.

Mein (klarer) Favorit ist apache2-mpm-worker + libapache2-mod-fcgid + php-apc, wer einfachere Konfigurationen bevorzugt und bei dem Benutzerrechte keine Rolle spielen ist auch mit apache2-mpm-prefork + libapache2-mod-php5 + php-apc gut bedient.

Papierkorb für gelöschte Dateien

caticonslite_bm_alt

Vielen ist bekannt, dass TYPO3 einen Verlauf zum Wiederherstellen von gelöschten Seiten und Inhalten bietet. Dass für Dateien ein ähnliches Feature existiert wissen dagegen nur die wenigsten: Erstellt man unter „fileadmin“ einen Ordner namens „_recycler_“, so dient dieser ab sofort als Papierkorb für gelöschte Dateien. Außerdem ist es möglich in der kompletten Ordnerstruktur unter „fileadmin“ „_recycler_“-Ordner anzulegen, gelöschte Dateien werden daraufhin im in der Hierarchie nächstgelegenen Papierkorb abgelegt – das ist vor allem beim Einsatz von Benutzergruppen interessant.

Vererbung von Bildern aus den Seiteneigenschaften

caticonslite_bm_alt

In TYPO3 lassen sich in den Seiteneigenschaften Bilder im Feld „Dateien“ unter „Ressourcen“ hinterlegen. Auf die angegebenen Dateien kann man mit TypoScript zugreifen und somit z.B. je Seite ein individuelles Headerbild darstellen. Häufig ist es ausreichend auf Unterseiten das Bild der übergeordneten Seite anzuzeigen, oder man möchte nicht auf jeder Seite ein Bild hinterlegen müssen. Hierfür bietet sich in TYPO3 die Verwendung von „slide“ an – damit lässt sich eine Vererbung von Bildern realisieren. D.h. es wird ausgehend von der aufgerufenen Seite der Seitenbaum bis zur Rootseite nach einem Bild durchsucht, bis entweder ein Bild gefunden, oder die Rootseite erreicht worden ist.

Bei einer TYPO3 Standard-Installation mit FAL (File Abstraction Layer) (ab TYPO3 6.0) benötigt man folgendes TypoScript:

lib.image = FILES
lib.image {
	references {
		data = levelmedia:-1,slide
	}
	renderObj = IMAGE
	renderObj {
		file.import.data = file:current:publicUrl
		titleText.data = file:current:title
	}
}

Bei einer TYPO3 Standard-Installation ohne FAL (bis TYPO3 6.0) benötigt man folgendes TypoScript:

lib.image = IMAGE
lib.image.file {
	import = uploads/media/
	import {
		data = levelmedia:-1, slide
		listNum = 0
	}
}

Wird DAM verwendet, ist folgende Konfiguration zu verwenden:

lib.image = IMAGE
lib.image.file {
	import.cObject = USER
	import.cObject {
		userFunc = tx_dam_pages->get_media_file
		listNum = 0
		slide = 1
	}
}

Individuelle Marker in Direct Mail

caticonslite_bm_alt

In einem Newsletter werden häufig auch benutzerspezifische Parameter abseits der standardmäßig vorhandenen benötigt, z.B. um die Anrede zu personalisieren (Sehr geehrte Frau bzw. Sehr geehrter Herr,…) oder um Felder aus marketingtechnischen Gründen (z.B. individueller Gewinncode) hinzuzufügen. Dies ist in der Direct Mail-Extension (Extensionkey: direct_mail), dank der Verwendung von Hooks, relativ einfach zu bewerkstelligen.

Zuerst muss man hierfür eine neue Extension erstellen, ich verwende hier den Extensionkey „direct_mail_markers“, um die benötigten Dateien irgendwo ablegen zu können. Als nächstes wird eine Klasse (samt entsprechender Methode), welche benutzerdefinierte Marker generiert, erstellt – im Ordner „Classes/Hooks/“ der Extension legt man eine Datei namens „DirectMailMarkers.php“ mit folgendem Inhalt an:

<?php
namespace WebentwicklerAt\DirectMailMarkers\Hooks;
 
class DirectMailMarkers
{
    /**
     * @param array $params
     * @return array
     */
    function mailMarkersHook(array $params)
    {
        // ###USER_salutation###
        $salutation = '';
        if (in_array($params['row']['gender'], array(0, 'm', 1, 'f')) && !empty($params['row']['last_name'])) {
            // gender
            if ($params['row']['gender'] === 0 || $params['row']['gender'] === 'm') {
                $salutation = 'Sehr geehrter Herr ';
            } else if ($params['row']['gender'] === 1 || $params['row']['gender'] === 'f') {
                $salutation = 'Sehr geehrte Frau ';
            } else {
                $salutation = 'Sehr geehrte(r) Herr/Frau ';
            }
 
            // title
            if (!empty($params['row']['title'])) {
                $salutation .= $params['row']['title'] . ' ';
            }
 
            // last_name
            $salutation .= $params['row']['last_name'];
        } else {
            $salutation = 'Sehr geehrte Damen und Herren';
        }
 
        $params['markers']['###USER_salutation###'] = $salutation;
 
        return $params;
    }
}

Diese Methode erzeugt abhängig vom Feld „gender“ die persönliche Anrede „Sehr geehrter Herr Nachname“, „Sehr geehrte Frau Nachname“ oder wenn kein Nachname oder Geschlecht angegeben worden ist „Sehr geehrte Damen und Herren“. Zusätzlich wird der Titel – sofern angegeben – eingefügt.

Damit die soeben erstellte Hook-Methode verwendet wird und der generierte Marker ###USER_salutation### im Newsletter verwendet werden kann, muss diese in der„ext_localconf.php“ registriert werden:

<?php
 
if (!defined ('TYPO3_MODE')) die ('Access denied.');
 
// register directmail markers hook
$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['ext/direct_mail']['res/scripts/class.dmailer.php']['mailMarkersHook'][] = 'EXT:' . $_EXTKEY . '/Classes/Hooks/DirectMailMarkers.php:' . \WebentwicklerAt\DirectMailMarkers\Hooks\DirectMailMarkers::class . '->mailMarkersHook';

Nachdem die soeben erstellte Erweiterung über den Extensionmanager installiert worden ist, steht der generierte Marker im Newsletter zur Verfügung.

In der Datei composer.json der Installation ist folgender Eintrag für das Autoloading unter „autoload/psr-4“ zu ergänzen:

"autoload": {
  "psr-4": {
    "WebentwicklerAt\\DirectMailMarkers\\": "typo3conf/ext/direct_mail_markers/Classes/"
  }
}

Abschließend müssen die Autoloading-Informationen noch mit composer dump-autoload aktualisiert werden.

RSS-Feed generieren

caticonslite_bm_alt

Viele TYPO3-Erweiterungen zur Generierung von RSS-Feeds können lediglich Seiten und tt_news-Artikel verwenden – das ist häufig nicht ausreichend. Eine Ausnahme bildet die Extension „in2rss“, welche sich recht flexibel mittels TypoScript konfigurieren lässt und Datensätze aus jeder beliebigen Tabelle darstellen kann.

Nach der üblichen Vorgehensweise zur Installation des Plugins, müssen noch die zu verwendendenTabellen konfiguriert werden. Die Grundkonfiguration samt einem vorkonfigurierten Beispiel lässt sich mittels Static Template einfügen – dieses erscheint mir allerdings als unpraktikabel, daher lege ich alle notwendigen Parameter selbst im Setup fest:

includeLibs.in2rss_main = EXT:in2rss/lib/class.tx_in2rss_main.php
 
rss = PAGE
rss {
	typeNum = 100
 
	config {
		disableAllHeaderCode = 1
		disablePrefixComment = 1
		xhtml_cleaning = 0
		admPanel = 0
		no_cache = 1
	}
 
	10 = USER
	10 {
		userFunc = user_in2rss_main->showRSS
		userFunc.config {
			template = fileadmin/templates/webentwickler/in2rss/template.xml
			sorting = DESC
			limit = 20
			uft8_coding =
 
			10 {
				settings {
					table = pages
					fieldTitle = title
					fieldDescription = description
					fieldBody = description
					fieldImage = media
					fieldSorting = crdate
					fieldCrdate = crdate
					pid =
					pid_recursive = 0
					additionalWhereClause = AND doktype IN (1) AND nav_hide = 0
					cropDescription = 250
					limit = 100
				}
 
				fields {
					rssTitle = TEXT
					rssTitle {
						field = rssTitle
					}
 
					rssDescription = TEXT
					rssDescription {
						field = rssDescription
					}
 
					rssBody = TEXT
					rssBody {
						field = rssBody
					}
 
					rssSorting = TEXT
					rssSorting {
						field = rssSorting
					}
 
					rssCrdate = TEXT
					rssCrdate {
						field = rssCrdate
					}
 
					rssLink = TEXT
					rssLink {
						typolink {
							parameter.field = uid
							returnLast = url
						}
					}
				}
			}
		}
	}
}
 
[globalVar = GP:type = 100]
	config.absRefPrefix = {$baseUrl}
[end]

Die Konfiguration der Tabelle erfolgt in den Zeilen 24-74, in diesem Fall werden alle nicht im Menü versteckten (nav_hide = 0) Seiten (table = pages) vom Typ Standard (doktype IN (1)) verwendet. Die restlichen Zeilen dieses Bereichs enthalten Parameterzuweisungen, damit diese im in Zeile 19 angegebenen Template verwendet werden können:

<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0">
	<channel>
		<title>webentwickler.at</title>
		<link>http://www.webentwickler.at/</link>
		<description>Blog für Webentwickler.</description>
		<language>de</language>
 
		<f:for each="{rssFeed}" as="rss"><f:if condition="{rss.rssTitle}">
			<item>
				<title>{rss.rssTitle}</title>
				<description>{rss.rssDescription}</description>
				<link>{rss.rssLink}</link>
				<pubDate>{rss.rssCrdate}</pubDate>
			</item>
		</f:if></f:for>
	</channel>
</rss>
1 2 3 4 5 6  nach oben