UserFunction:

<?php
class user_getextimage {
  function main($content,$conf) {
    $url = $conf['url'];
 
    if ( empty($conf['filename']) ) {
      $targetFile = $conf['targetPath'].hash('adler32',$url).".".$conf['fileExt'];
    } else $targetFile = $conf['targetPath'].$conf['filename'].".".$conf['fileExt'];
 
    # Wenn Datei noch nicht zu alt ist gleich zurückliefern anstatt neu laden
    if ( file_exists($targetFile) ) {
      $lastModified = filemtime($targetFile);
      $currentTime  = time();
 
      if ( ($lastModified + $conf['cacheTimeout']) > $currentTime ) return $targetFile;
    }
    // Anfrage ausfuehren und ausgeben
    file_put_contents($targetFile,t3lib_div::getUrl($url));
 
    // PFad liefern
    return $targetFile;
  }
}
?>

Setup:

plugin.tx_tsselect_pi1.objList.imageTest.title = Image Test
plugin.tx_tsselect_pi1.objList.imageTest.cObject = IMAGE
plugin.tx_tsselect_pi1.objList.imageTest.cObject {
  file.import.stdWrap.cObject = USER
  file.import.stdWrap.cObject {
    includeLibs = fileadmin/user_getextimage/user_getextimage.class.php
    userFunc   = user_getExtImage->main
 
    url          = http://lorempixel.com/450/350/
 
    targetPath   = fileadmin/user_getextimage/
    fileExt      = jpg
    filename     = extImage
    cacheTimeout = 300
  }
 
  file.maxW = 150
  file.maxH = 150
 
  imageLinkWrap = 1
  imageLinkWrap.enable = 1
  imageLinkWrap.typolink {
    parameter.cObject < plugin.tx_tsselect_pi1.objList.imageTest.cObject.file.import.stdWrap.cObject
    ATagParams = class="lightbox" rel="lightbox[galerie]"
  }
 
  wrap = |<br />Source from: http://lorempixel.com/
}

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Begonnen bei der Systemsicherheit vielen Schlagwörter wie CHROOT-Technik, detailliertes Monitoring, Linux (monolithische Kernal) und Anonymisierung nach draußen. Das Kundencenter soll natürlich dem Kunden helfen die Features zu benutzen. Der Softwaremanager bietet Ein-Klick-Installationen mit den benötigten Komponenten, der Versionsmanager die passenden Updates.

Sicherheits-Services werden im Hintergrund automatisch durchgeführt (das betrifft z.B. Sicherheitspatches und Wartung-E-Mails). Der Wiederherstellungsmanager bietet die Möglichkeit alte Zustände wiederherzustellen. Alle Aktionen werden mit E-Mails bestätigt.

Leider gab es wenig Informationen zu sicherem Hosting(habe mir technische Details gewünscht ), sondern es war mehr eine Verkaufssession. Dennoch einige interssante Funktionen welche man gerne bei einem Hoster sieht.

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Wenn es Euch interessiert könnt Ihr Euch über die Shell mit dem mysql-Befehl auf den Server einloggen und das Profiling aktivieren:

SET profiling = 1;

Alle nun über die MySQL-Shell eingegebenen Abfragen werden protokolliert und können sehr detailliert analysiert werden. Mach nun mal ein einfaches SELECT auf die fe_users:

SELECT * FROM fe_users;

Führt danach direkt noch diesen Befehl aus:

SHOW profile CPU FOR QUERY 1;

In dieser Aufstellung seht Ihr nun, wie lange der MySQL-Server für jede durchgeführte Aufgabe gebraucht hat. Bei mir sind es 16 Aufgaben, die der Server abarbeiten musste. Nun stellt Euch mal folgendes PHP-Konstrukt vor, dass alle Inhaltselemente zu den entsprechenden Seiten raussucht:

$res = $GLOBALS['TYPO3_DB']->exec_SELECTquery(
	'SQL_NO_CACHE uid, title',
	'pages',
	'1=1 ' .
	$this->cObj->enableFields('pages'),
	'', '', ''
);
while($page = $GLOBALS['TYPO3_DB']->sql_fetch_assoc($res)) {
	$content .= '<p>' . $page['title'] . ':</p><ul>';
	$res2 = $GLOBALS['TYPO3_DB']->exec_SELECTquery(
		'SQL_NO_CACHE uid, header',
		'tt_content',
		'pid = ' . $page['uid'] . '
		' . $this->cObj->enableFields('tt_content'),
		'', '', ''
	);
	while($data = $GLOBALS['TYPO3_DB']->sql_fetch_assoc($res2)) {
		$content .= '<li>' . $data['header'] . '</li>';
	}
	$content .= '</ul>';
}

Solche Konstrukte findet man immer wieder in Extensions vor. Allerdings wird hier für jede Seite eine neue Anfrage an den Server gesendet. Zwar hat der MySQL-Server einen Cache, auf den er zugreifen kann, aber bis zu dieser Entscheidung muss der MySQL-Server immer wieder bestimmte Aufgaben zwecks Überprüfung durchführen.

Mit den nun eingeführten PREPARED-Abfragen, können wir dem MySQL-Server eine vorbereitete Abfrage mit Platzhaltern senden. Diese Abfrage wird EINMAL vom Server verarbeitet und alle Abfragen danach (mit unterschiedlichen Platzhaltern) können direkt und OHNE weitere Operationen und Parsen abgearbeitet werden. Statt den vorherigen 16 Aufgaben müssen nun vielleicht nur noch 6 oder 8 Aufgaben ausgeführt werden. Dieser Wegfall von Aufgaben wirkt sich natürlich positiv auf die Verarbeitungszeit aus.

TYPO3 bringt seit der 4.5er Version eine neue Klasse “class.t3lib_db_preparedstatement.php” mit, mit der diese vorbereiteten Abfragen realisiert werden können. Doch Achtung! Schaut Euch die Datei mal an. Überall sind Verweise auf die ganz normalen SELECT-Methoden der t3lib_db zu finden. Wie kann das also schneller sein? Die Antwort ist einfach: Gar nicht! Ich habe es mehrfach getestet. Aber ein Eintrag in der TYPO3-Dev-Liste lässt hoffen. Ich habe erfahren, dass TYPO3 wohl in Zukunft auf mysqli wechseln möchte. Diese Objektorientierte Art des MySQL-Zugriffs bringt unteranderem auch Methoden mit, um diese PREPARED-Statements zu verarbeiten. Die neue TYPO3-Klasse ist derzeit also nur ein Dummy und wird, wenn es dann mal so weit ist auch tatsächlich einen Performanceschub bringen.

Hier mal das gleiche Beispiel von oben auf Basis von PREPARED-Statements:

$GLOBALS['TYPO3_DB']->sql_query('PREPARE contentStmt FROM "
	SELECT SQL_NO_CACHE uid, header
	FROM tt_content
	WHERE pid = ? ' . $this->cObj->enableFields('tt_content') . '
"');
$res = $GLOBALS['TYPO3_DB']->exec_SELECTquery(
	'SQL_NO_CACHE uid, title',
	'pages',
	'1=1 ' .
	$this->cObj->enableFields('pages'),
	'', '', ''
);
//t3lib_div::devLog('db', 'db', -1, array($res));
while($page = $GLOBALS['TYPO3_DB']->sql_fetch_assoc($res)) {
	$content .= '<p>' . $page['title'] . ':</p><ul>';
	$GLOBALS['TYPO3_DB']->sql_query('SET @uid = ' . $page['uid']);
	$res2 = $GLOBALS['TYPO3_DB']->sql_query('
		EXECUTE contentStmt USING @uid;
	');
	while($data = $GLOBALS['TYPO3_DB']->sql_fetch_assoc($res2)) {
		$content .= '<li>' . $data['header'] . '</li>';
	}
	$content .= '</ul>';
}
$GLOBALS['TYPO3_DB']->sql_query('DEALLOCATE PREPARE contentStmt');

Ihr seht, dass prepare_SELECTquery ein Object und nicht mehr einen MySQL-Link zurück gibt. Ansonsten bleiben die übergebenen Variablen für fields, table und where nahezu gleich. Bis auf den Punkt in der WHERE-Clause: Hier könnt Ihr nun mit dem Doppelpunkt-Parameter Platzhalter definieren, die Ihr später mal ersetzen wollt (:uid). Später könnt Ihr mit der Methode “execute()” diese Doppelpunkt-Platzhalter mit Werten ersetzen und die Daten mit der Methode “fetch()” abrufen. Alle vorbereiteten Abfragen werden im MySQL-Cache vorbehalten und nehmen Platz im Speicher ein. Um diesen wieder freizugeben solltet Ihr mit der Methode “free()” diesen Platz wieder freigeben.

An dieser Stelle will ich Euch noch einen Punkt beschreiben mit dem man wirklich mal Speed in seine Abfragen reinbringen kann. Ich möchte Euch aber auch noch darauf aufmerksam machen, dass diese hier gezeigte Variante nicht DBAL kompatibel ist:

$GLOBALS['TYPO3_DB']->sql_query('PREPARE contentStmt FROM "
SELECT SQL_NO_CACHE uid, header
FROM tt_content
WHERE pid = ? ' . $this->cObj->enableFields('tt_content') . '
"');
 
$res = $GLOBALS['TYPO3_DB']->exec_SELECTquery(
'SQL_NO_CACHE uid, title',
'pages',
'1=1 ' .
$this->cObj->enableFields('pages'),
'', '', ''
);
//t3lib_div::devLog('db', 'db', -1, array($res));
while($page = $GLOBALS['TYPO3_DB']->sql_fetch_assoc($res)) {
$content .= '<p>' . $page['title'] . ':</p><ul>';
$GLOBALS['TYPO3_DB']->sql_query('SET @uid = ' . $page['uid']);
$res2 = $GLOBALS['TYPO3_DB']->sql_query('
EXECUTE contentStmt USING @uid;
');
while($data = $GLOBALS['TYPO3_DB']->sql_fetch_assoc($res2)) {
$content .= '<li>' . $data['header'] . '</li>';
}
$content .= '</ul>';
}
$GLOBALS['TYPO3_DB']->sql_query('DEALLOCATE PREPARE contentStmt');

So werden irgendwann mal die von TYPO3 verarbeiteten Abfragen aussehen. Ich habe diese drei Abfragen mal in einer Extension zusammengeschnürt: http://typo3.sfroemken.de/?id=213. Evtl. werdet Ihr bemerken, dass die PREPARED-Queries bei wenigen Durchläufen nicht wirklich Speed bringen. Jeder SQL-Befehl, der zum Server gesendet werden muss braucht Zeit. Einmal für die PREPARED-Query und einmal für den eigentlichen SELECT-Query. Verwendet also bitte nicht für jeden SELECT die PREPARED-Statements. Setzt Sie bitte nur dann ein, wenn Ihr mehrere ähnliche SELECTs absetzen müsst. Erst dann entfaltet sich die wahre Performance. Bei einer Indexierung von über 50.000 Datensätzen konnte ich über 30% Geschwindigkeit rausholen.

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Server Map (Klick-Vergrößerung)

Ein kurzer beschrieb zur Architektur:
Es gibt zwei DB Server. Einer physikalisch einer virtuell. Diesen könnten synchronisiert und als Backup zu dienen. Eine weitere Möglichkeit könnte auch ein Master / Slave Konzept sein. Dabei hinterlegt man zwei Datenverbindungen an sodass im Ausfall des Master Servers der Slave Server einspringt und die Verfügbarkeit sichert. Auf dem physikalischen DB Server könnte auch der Tomcat für die Solr Indizierung und andere Dienste und Datenbanken laufen.

Der VM1 ist ein virtueller Webserver wie Apache. Diesen Server könnte man beliebig für Testsysteme klonen und bei Bedarf skalieren oder gar in die Cloud auslagern.

Der VM2 ist ein virtueller Reverse Proxy in einer DMZ zwecks Sicherheit. Dort liegen gecachte Seiten um die Performance hoch zu halten.

Weitere zu beachtende Punkte:

• MySQL unterstützt nur einen Server mit Schreibmöglichkeiten, daher könnte Loadbalancing oder Hot-Standby sehr instabil werden.
• Persistent Connect wäre hier gut um Performance Verluste zu vermeiden. Denn jeder neue Connect auf die DB kostet 20 ms. Im TYPO3 könnte das aber auch zu Problemen führen.
• TYPO3 kann man technisch nicht komplett in Frontend und Backend aufteilen, da es überall Schnittstellen gibt. Das Frontend hat viele Gebiete in denen Inhalte geschrieben werden.
• Gerne freu’ ich mich über eure Erfahrungen mit großen TYPO3 Instanzen.

Dies ist ein Gastbeitrag von Thomas Wittek für die “Alles muss raus” Aktion.

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Das Ergebniss ist eine Liste aller Requests die einen 404 auslösen mit der jeweiligen Anzahl davor.
Das Ganze nach Häufigkeit sortiert.

Keine Raketentechnik, aber praktisch und daher worth sharing .

Für den geneigten Leser:

• access.log nach 404 grepen
• Zeile bei ‘ ‘ splitten und 7te spalte isolieren (bei anderem Logformat anpassen)
• Sortieren
• Gleiche Zeilen zusammenfassen und Zähler versehen
• Nummerisch absteigend sortieren

Wer sich das ganze gleich per Mail schicken lassen möchte, kann hinten noch ein | sendmail abx@xyz.de dranhängen.

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Update von Extensions verhindern (Extension Manager)

Die Einstellung “excludeFromUpdates” mit dem Wert 1 in der Datei ext_emconf.php verhindert, dass diese Extension durch den Extension Manager aktualisiert werden kann. Besonders nützlich wenn man doch einmal den Code einer Extension direkt verändert hat und ein Update mit anschließendem Verlust der eigenen Änderungen verhindern will. XCLASS und Hooks sind natürlich dennoch vorzuziehen.

Einstellung doNotLoadInFE (Programmierung)

Ebenfalls in der Datei ext_emconf kann nun die Einstellung doNotLoadInFE gesetzt werden. Damit wird das Frontend etwas schneller, da nur noch die Extensions bzw. dessen ext_tables.php und ext_localconf.php-Einstellungen geladen werden, deren Wert nicht auf 1 gesetzt ist.

Neuer TCA-Typ “suggest” (Programmierung)

Nach langer Zeit im Bugtracker hat es auch dieses Feature in die 4.3. geschafft. Damit es sehr einfach möglich, ein Suggest/Autocomplete Feld im Backend zu generieren. Besonders nützlich wenn eine Verknüpfung zu einer Datenbanktabelle geschaffen werden soll, in der es viele Einträge gibt. Die Konfiguration findet entweder über das TCA oder über das Seiten TsConfig statt. Beispiel-Code:

$TCA['pages']['columns']['storage_pid']['config']['wizards']['suggest'] = array(
	'type' => 'suggest',
	'default' => array(
		'pidList' => '1,2,3,45',
	),
);

cObject CONTENT erlaubt Aufruffe von den Tabellen static_ (TypoScript)

Bis jetzt konnte mit dem cObj CONTENT nur folgende Tabellen abgefragt werden: pages, tt_content, fe_*, tx_*, tt_*, user_*. Jetzt ist auch static_ möglich.

TS-Eigenschaft stripProfile (TypoScript)

Die Eigenschaft stripProile erlaubt es bei den cObjects IMAGE/IMG_RESOURCE, dass beim Verkleinern die Bildprofile gelöscht werden. Damit werden die Bilder kleiner.  Mit der Einstellung “im_useStripProfileByDefault” kann dieses Feature im Extension Manager global aktiviert (und per TypoScript für bestimmte Fälle deaktiviert werden). Beispiel-Code:

10 = IMAGE
10.file = fileadmin/images/image1.jpg
10.file.stripProfile = 1

t3editor mit auto complete (Backend)

Wie bereits von Tobias Liebig erwähnt beherrscht der t3editor nun auch ein autocomplete – besonders fein für alle, die die TsRef noch immer nicht auswendig können

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Vergrößerbare Textareas (Backend)

Alle Textareas, die über TCEforms gerendert werden, können nun über JavaScript vergrößert werden und zwar sowohl horizontal als auch vertikal. Zusätzlich verlängert sich der Eingabebereich voll automatisch mit einem netten Effekt wenn eine neue Zeile hinzukommt. An dieser Stelle Danke an Steffen für die tolle Arbeit!

Shortcuts deaktivierbar (Backend)

Mit dem Code “options.enableShortcuts = 0″ im User TsConfig lässt sich die Shortcut-Option deaktivieren. Das führt zu weniger Icons und sauberen Backend – sehr nützlich wenn man die Shortcuts nicht nützt.

Versionierung & Workspaces deaktivierbar (Backend)

Seit 4.3. ist die Extension version keine Pflichtextension mehr und kann deaktiviert werden. Die Perfomance des Backends profitiert davon, da einige Queries weniger gesetzt werden müssen. Zum Aktivieren muss die Extension installiert werden bzw kann dies über den Update-Wizard erledigt werden.

Ausgelagerte System-Extensions (Backend)

Folgende Funktionalitäten wurden ebenso in System-Extensions ausgelagert und sind nun optional und über den Extension Manager deaktvierbar:

• Help>About [about]:  Shows info about TYPO3 and installed extensions.
• Help>TYPO3 Manual [cshmanual]: Shows TYPO3 inline user manual.
• Frontend Editing [feedit]: This module enables FE-editing, configuration is done by Typoscript.
• User>Open Documents [opendocs]: Handles the list of opened documents in TYPO3 backend.
• Simulate Static URLs [simulatestatic]: If you do not want to use RealURL or CoolURI but still want the Speaking URL feature.

Über den Update-Wizard können diese Extensions auch aktiviert werden.

stdWrap mit cropHTML (TypoScript)

Schon seit der Bier-Auktion auf der letzten T3BOARD ist dieses Feature fällig. Damit lässt sich endlich HTML-Code verkürzen ohne einen invaliden Code zu produzieren, da die HTML-Tags respektiert und wieder korrekt geschlossen werden.

stdWrap für imageLinkWrap (TypoScript)

Damit ist es möglich, Bilder zu überschreiben, beispielsweise für andere Bilder in einem Popup mit folgendem Code

tt_content.image.20.1.imageLinkWrap.file.override.cObject {
field = tx_alternateimages_image
stdWrap {
required = 1
wrap = uploads/pics/|
}
listNum < tt_content.image.20.1.imageLinkWrap.enable.ifEmpty.typolink.parameter.listNum
}

Verbesserungen im Database-Analyser (Install-Tool)

Mit der Version 4.3. gibt es eine Checkbox, um alle anderen Checkboxen zu aktivieren, man spart sich also jede Menge geklickse, auch dafür danke!

Hinweis: Wer von weiteren Features weiß, die ich vielleicht vergessen könnte aber erwähnenswert sind, bitte einfach bei mir kurz melden – danke!

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Auf typofree.org wurde nun erklärt wie man TYPO3 auf das System bekommt und die Performance weiter ausreißt indem man mit gzip / Header arbeitet und den Static File Cache aktiviert. Wirklich gute Artikel. Ich werde mir den Webserver mal anschauen, kann aber (auch wenn er gut ist) nicht wechseln, weil ich da an meinen Hoster gebunden bin.

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Also bitte verwendet diese Einstellung nie, auch nie zur Entwicklung! Gerade hier sollte man so real wie möglich testen und dann fallen diverse Probleme sofort auf!

Alternativen:

• Cache der Seite auf ein paar Minuten stellen, das bringt schon sehr viel
• USER_INT / COA_INT wenns wirklich nicht gecached werden darf
• generell vorher überlegen wie gewisse Logiken implementiert werden können
• Extension coago

Wie bereits in http://typo3blogger.de/cache-probleme-mit-typo3/ beschrieben, kann im Install-Tool mit [FE][disableNoCacheParameter] = 1 verhindert werden, dass das no_cache greift!

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

PS: Die Texte wurde leicht an den Blog-Slang (gibt es das) angepasst.

Bevor die exakten Testfälle analysiert und ausgewertet werden, wird der Ablauf einer Client-Anfrage an eine TYPO3 Webseite erläutert. Für jeden Prozessschritt werden Optimierungspotentiale definiert, anhand denen man die Performance Tests ansetzen kann, um die Geschwindigkeit der Webseite zu steigern. Diese Übersicht dient den nachfolgenden Analysen, um aufzuzeigen welche Möglichkeiten zur Optimierung gegeben sind.

Hinweis: Das Optimierungspotential ist stichpunktartig formuliert und kann weiter definiert werden.

Die Performance einer Webseite baut auf viele verschiedene Prozesse auf. Bei einem Request an einen Webserver müssen nicht zwingend alle Prozesse abgearbeitet werden. Durch das Cachen von Daten auf den verschiedenen Ebenen der Anfrage, kann man die Reaktionszeit der Webseite verkürzen. Die Abbildung (s.o.) verdeutlicht den Weg der zurück gelegt werden muss, wenn eine Webseite geladen wird. Das Schaubild ist dabei ausschließlich auf TYPO3 bezogen, ähnelt aber einer normalen Webseiten-Anfrage sehr stark.

DNS

Das “Domain Name System” ist ein zentrales Element des heutigen Internet. Die DNS-Server kümmern sich um die Zuweisung von Hostnamen (z.B. www.google.de) auf IP Adressen. Dieser Schritt ist somit der erste Schritt der bei einer Anfrage gemacht wird. Bei einem ersten Zugriff auf eine Webseite ist die Auflösung des Hostnames ein unvermeidbarer Vorgang. Die dazugehörige IP Adresse wird im Anschluss lokal und auch beim Provider gespeichert und nur im Fehlerfall erneut mit einem DNS-Server verifiziert.

Optimierungspotential:

• Die TTL (“Time to Live”) Zeit der Domain herauf setzen. Die TTL wird vom Master Nameserver definiert und legt fest, wie lange andere Namensserver die IP mit der dazugehörigen Domain speichern dürfen. (DNS Cache)

Apache (Webserver)

Nachdem der Client die IP Adresse erhalten hat, beginnt die eigentliche Anfrage an den Webserver. Der Apache(The Apache Software Foundation) ist das Webserver System, welches weltweit am meisten verbreitet ist. Der Apache wird vorzugsweise auf UNIX Plattformen betrieben. Durch zahlreiche Module lässt sich der Funktionsumfang des Apaches ausbauen, um z.B. Daten zu komprimieren oder Weiterleitungen durchzuführen. Die Aufgabe des Apache ist es, die Anfragen des Benutzers (Clients) entgegen zu nehmen und den passenden internen Prozess anzustoßen. Dabei geht es nicht ausschließlich um TYPO3 Anfragen, sondern auch um alle anderen Arten von Anfragen, die der Apache verwaltet (Bilder, Cascading Style Sheets, Javascript, Flash etc.).

Optimierungspotential:

• Den Request-Overhead reduzieren, indem man nicht benutze Apache-Module deaktiviert.
• PHP mit einem anderen Mechanismus laden. Es gibt mehrere Wege PHP in den Apache zu integrieren. Als Modul, FastCGI oder CGI. FastCGI stellt die modernste Methode dar.
• HTTP Cache Headers bzw. Expires Header um gesendete Dateien dauerhaft beim Client zu Cachen.
• TYPO3 nicht laden, indem man TYPO3-Seiten in statische Dateien ablegt und diese direkt vom Apache ausliefern lässt.

PHP (Skriptsprache)

Die interpretierte Skriptsprache PHP (Rekursives Akronym für ‘PHP: Hypertext Preprocessor’) ist das Modul, welches der Apache direkt nach dem Request lädt, wenn es zu einem normalen TYPO3 Request kommt. TYPO3 ist komplett in PHP programmiert worden und ist somit erforderlich für den Betrieb des Content Management Systems.

Optimierungspotential:

• PHP Beschleuniger interpretieren PHP einmalig und cachen PHP in einer Art Byte-Code, der deutlich schneller in der Ausführungszeit ist, weil ein erneutes interpretieren nicht notwendig ist.
• PHP interne Optimierung in Schleifen, Strings und Funktionen. Bestimmte Schleifenkonstrukte und Funktionen laufen schneller als andere, trotz des gleichen Ergebnisses.
• Programmstrukturen oder Design Patterns benutzen die Arbeitsspeicher beim durchlaufen einsparen. So kann man z.B. mittels des Singleton Patterns Objekte einmalig machen, anstatt bei jedem gebrauch des Objektes eine neue Instanz zu erstellen.
• Cachen von Ausgaben, um unnötiges Durchlaufen von Funktionen zu verhindern.

TYPO3

TYPO3 ist der Flaschenhals der serverseitigen Performance. Es ist in PHP entwickelt und interagiert mit der MySQL Datenbank. TYPO3 wird dabei in das Frontend (FE) und in das Backend (BE) unterteilt, die bei der Optimierung separat betrachtet werden.

TYPO3 – Frontend

Das Frontend von TYPO3 stellt die eigentliche Ausgabe zum Browser dar. Die Ausgabe ist Format unabhängig, erfolgt aber in 99% der Fälle in einem von Webbrowsern lesbaren Format (XML oder XHML). Bilder und andere Elemente wie Javascript und CSS, werden vom TYPO3 Frontend generiert und statisch im Dateisystem abgelegt.

Optimierungspotential:

• PHP Optimierung (siehe PHP Optimierungspotential).
• TYPO3 Caches spielen eine Größe Rolle, um die Performance zu steigern. TYPO3 Caches gibt es sowohl für die TYPO3 interne Konfigurationssprache TypoScript als auch auf Seitenebene für Contentelemente.
• Der TYPO3 Static File Cache legt die komplette Ausgabe von TYPO3 im Dateisystem ab, damit der Apache TYPO3 bei einer Anfrage nicht mehr laden muss.

TYPO3 – Backend

Das Backend dient der Verwaltung der TYPO3-Webseite. Das Cachen von Inhalten ist hier nur sehr schwer möglich, weil die Ansicht eines Redakteurs immer aktuell sein muss.

Optimierungspotential:

• Cachen von Icon’s (Grafiken), Javascript und CSS für das TYPO3 Backend.
• Technologien wie Google Gears implementieren, um eventuell sogar Datenbanken beim Client zu speichern.

MySQL (Datenbank)

MySQL ist das primäre Datenbank-System hinter TYPO3. Durch die TYPO3 Datenbankabstraktion ist es möglich andere Datenbanken an das Content Management System anzubinden. Von diesem Schritt wird aber abgeraten, weil es zu Komplikationen kommen kann, wenn Extensions benutzt werden, die nicht die TYPO3 API (Application Programming Interface, de. “Programmierschnittstelle”) benutzen. Damit der Abstraktionslayer die Datenbankabfragen für verschiedene Systeme zusammen bauen kann, ist man dazu gezwungen, Kompromisse in SQL einzugehen, weshalb man nicht alle Queries perfektionieren kann.

Optimierungspotential:

• Queries weitestgehend optimieren. Evtl. eine native angepasste Implementierung für MySQL als Hauptdatenbanksystem.
• Query Cache aktivieren. Seit der MySQL Version 4.x ist der Query Cache standardmäßig eingeschaltet. Durch TYPO3 wird aber die Funktionsweise zur Nichte gemacht, weil nahezu jede Query mit einem aktuellen Timestamp abgefragt wird.
• Redundante Query eliminieren, die im Rendering Prozess auftreten können.
• Query Resultsets cachen, um das Abfragen der Datenbank teilweise zu reduzieren.

Verbindung

Die Verbindung stellt ein großes Problem bei Webseiten dar, weil HTTP ein zustandsloses Protokoll ist. Das bedeutet, dass wenn eine Webseite viele Dateien enthält, der Aufbau der Webseite deutlich länger dauert, unabhängig davon wie groß diese Dateien sind. Das liegt dadran, dass ein HTTP Request einen sehr großen Overhead erzeugt und gegebenenfalls sogar das synchrone Laden der Webseite unterbinden kann. Man bedenke das eine Webseite die z.B. ein grafisches Menü besitzt, schnell an die 100 Anfragen generieren kann.

Optimierungspotential:

• HTTP Cache Headers bzw. Expires Header (siehe Apache).
• Javascript und CSS Dateien zusammenführen und komprimieren, um sowohl die HTTP Requests, als auch das Dateivolumen zu reduzieren.
• Wenn der anfragende Client GZip unterstützt, sollte man dies unbedingt nutzen um Javascript, CSS und XHTML zu komprimieren.

Rendering

Das Rendering im Browser des Clients stellt den letzten Schritt bei einer Anfrage an eine TYPO3 Seite (auch normalen Webseite ) dar. Beim Rendering ist ausschließlich die Leitung des Clients entscheidend. Dennoch kann man helfen ein möglichst schnelles und fehlerfreies Rendering zu gewährleisten.

Browser Rendering Engines unterscheiden zwei verschiedene Modi. Den “Standard mode” und den “Quirks mode”. Der Standard Modus ist deutlich schneller und beschreibt das Rendern von XHTML Seiten. Alle anderen Doctype Definitionen (HTML) fallen in den Quirks Modus zurück, der langsamer ist, weil er weitestgehend abwärtskompatibel ist.

Optimierungspotential:

• Valides XHTML, um den Standard Modus zu benutzen, der ein schnelleres Rendern verspricht.
• Valides CSS, um das Rendern der Webseite weiter zu beschleunigen.
• Javascript sollte am Ende des XHTML Dokuments geladen werden. Während es geladen wird, lädt der Browser keine anderen Dateien mehr, weil Javascript evtl. das HTML Dokument manipulieren könnte.

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Ergänzend zu diesem Beitrag wollte ich euch einfach einmal zeigen wie dies in einer Extension aussehen kann. Oft werden Extension nachträglich manipuliert und aus einer 1:n Beziehung kann mal schnell eine m:n Beziehung werden (Kundenwunsch ). Dies in TYPO3 zu realisieren ist nicht sehr aufwendig, aber bei einer Umstellung kann gerne mal was schief gehen.

Der einfachere Weg ist, den Datenbank Typ des betreffenden Feldes zu ändern (damit die kommaseparierte Liste aufgenommen werden kann) und im TCA das betreffende Feld nicht mehr begrenzen (zusätzlich vielleicht auch größer machen). In der Extension fragt man das betreffende Feld dann nur ein wenig anderes ab. Anstatt im WHERE String einen direkten vergleich zu machen…

 ... AND feldname=5 ...

wird nun eine TYPO3 Methode zur Hilfe genommen.

 ... AND '.$GLOBALS['TYPO3_DB']->listQuery('feldname',5,'tabellenname').' ...

Dadurch wird nun automatisch ein WHERE-Block generiert der die kommaseparierte Liste in den Datenbanken auflöst. Probiert es am besten selber mal aus.

PS: Performanter und schöner ist eine ordentliche Detail Tabelle!!

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Fangen wir einfach direkt mit den Files an…

TYPO3 bläht sich in Sachen Dateien schnell auf. Bei 99% der “Datei”-Felder im Backend wird eine Kopie der Datei im “uploads”-Verzeichnis hinterlegt, an welches normale Redakteure nicht heran kommen. Dies hat zum einen Vorteile zum anderen aber auch Nachteile. So ist die Seite z.B. dagegen geschützt das ein Redakteure ausversehen (Soll es ja geben ) eine falsche Datei im fileadmin löscht. Der Nachteil dieser Kopie ist, das es keinen Mechanismus gibt der die Datei löscht, sobald auch der Datensatz gelöscht wurde. Somit läuft der uploads Folder langsam aber sicher mit nicht mehr gebrauchten Bildern voll…

Nun gibt es zwei einfache Vorgehensweisen. Die simpelste ist die Installation der Extension kb_cleanfiles. Diese Extension vergleicht die Inhalte der Ordner mit den Referenzierungen in den dazugehörigen Datenbank Tabellen. Auf einen Blick sieht man Dateien die entfernt werden können. Durch einen weiteren Klick werden diese entfernt. Screenshot der Extension:

Eine Alternative zu der Extension ist das TYPO3 interne Modul. Zu finden ist das Modul unter “DB-Überprüfung” -> “Database Relations”. Neben dem Listing “Dateien, die in keinem Eintrag verwendet werden (bitte löschen!):”, welches der inhaltlichen Ausgabe der Extension sehr ähnelt, wird hier auch angezeigt ob Dateien doppelt referenziert werden (Das ist in TYPO3 nicht üblich und geschieht evtl. durch schlecht durchdachte Extensions. TYPO3 selbst erstellt immer eine Kopie und Nummeriert diese ggf. durch.). Auch wenn ihr dem TYPO3 Module evtl. mehr vertraut, habt ihr hier keine direkte löschen Funktion. Dies muss dann von Hand vorgenommen werden.

Die oben beschriebenen Techniken befreit den uploads-Folder von Altlast. Aber auch der “typo3temp”-Ordner wird schnell zu gemüllt. Dieser wird NICHT, wie viele denken, bei einem “FE-Clear-Cache” geleert. Generierte Bilder für FE und BE sowie GifBuilder Grafiken bleiben weiterhin bestehen. Deshalb ist auch hier ein aufräumen nach einer gewissen Zeit empfehlenswert. Dies geschieht am besten über das Install Tool mit dem man die Ordner nach und nach leeren kann (Siehe Screenshot)

Weiter geht es mit der Datenbank…

Neben den Dateien gibt es auch die Datenbank die gerne schnell voll läuft. TYPO3 hat die “gute” Eigenschaft nichts zu löschen, sondern Datensätze zu “flaggen” damit man diese leicht rekonstruieren bzw. wiederherstellen kann. Nun gibt es aber viele, viele Datensätze die wirklich nicht mehr benötigt werden (z.B. Testdaten der Erstbefüllung). Diese zu finden und zu löschen ist die Aufgabe der kj_recycler-Extension. In einem übersichtlichen Backendmodul bekommt man alle gelöschten Datensätze angezeigt, welche man dann “richtig” löschen kann. Achtung: Es gibt kein zurück!! Mein Tipp: Die Extension updated nicht den Referenz Index. Dieser sollte im Anschluss des Löschens manuell geupdated werden, damit dieser wieder richtig ist.

Eine weitere Last in der Datenbank können die Cache Tabellen sein. Temporäre Tabelle beginnen laut TYPO3 Namenkonvention mit dem Präfix “cache_”. Diese Tabellen können “im Normalfall” ohne weiteres geleert werden (nicht droppen). In die Liste würde ich gerne noch die “sys_histroy” aufnehmen. Diese Tabelle wird auch sehr schnell voll. Wichtig ist dabei aber, dass man wissen sollte das die Tabelle Aktionen der Backendaktivität enthält, die dadurch verloren gehen (Loginzeiten, Änderungen, History halt ).

Fazit

Durch die oben beschriebene Massnahmen könnt Ihr grade bei älteren TYPO3 Seiten ordentlich aufräumen und auch die Datenbank evtl. sogar beschleunigen (weniger ist manchmal mehr ). Ich empfehle jedoch vorher immer ein Backup zu machen.

Morgen wird das Türchen wieder im typo3weblog.de geöffnet.

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Kürzlich wurde dann dieser Beitrag veröffentlicht, der zahlreiche Präsentationen über MySQL Performance listet die sehr lesenswert sind. Alle Präsentationen werden von percona.com zum Download angeboten, wo es auch noch weitere gibt.

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

TYPO3 Housekeeping und TYPO3 Housekeeping 2

bekommt man die Infos, mal wieder “klar Schiff” zu machen.

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!