Typo3 - Performance optimieren: Unterschied zwischen den Versionen
| (2 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
| Zeile 57: | Zeile 57: | ||
tt_content.stdWrap.prefixComment > | tt_content.stdWrap.prefixComment > | ||
</pre> | </pre> | ||
| + | |||
| + | == Skripte und Styles == | ||
| + | === Mergen === | ||
| + | Zunächst werden CSS- und JavaScript-Dateien verkleinert, indem Whitespaces entfernt und Variablennamen gekürzt werden. Dann werden alle auszuliefernden CSS- und JavaScript-Dateien jeweils zu einer einzigen Datei zusammengefasst und anschließend noch komprimiert. | ||
| + | |||
| + | Das kann TYPO3 von Haus aus | ||
| + | |||
| + | === Inline-Styles und JS auslagern === | ||
| + | config.removeDefaultJS = external | ||
| + | config.inlineStyle2TempFile = 1 | ||
| + | |||
| + | === CSS Sprites === | ||
| + | Bei vielen Grafiken spart das Zugriffe | ||
== Objekte die Caching verhindern vermeiden == | == Objekte die Caching verhindern vermeiden == | ||
| Zeile 67: | Zeile 80: | ||
== Browser Caching == | == Browser Caching == | ||
| − | Weiß dieser etwa, dass sich die Seite überhaupt nicht verändert hat, muss er diese nicht extra anfordern und spart somit wertvolle Übertragungszeit. Dafür muss dem Browser aber erst mitgeteilt werden, wie lange die Seite im Cache vorgehalten werden soll. Dafür werden so genannte Cache-Header verwendet, die per HTTP-Header mit jedem Response übertragen werden. Diese schaltet man im TypoScript-Setup wie folgt ein: | + | Weiß dieser etwa, dass sich die Seite überhaupt nicht verändert hat, muss er diese nicht extra anfordern und spart somit wertvolle Übertragungszeit. Dafür muss dem Browser aber erst mitgeteilt werden, wie lange die Seite im Cache vorgehalten werden soll. Dafür werden so genannte Cache-Header verwendet, die per HTTP-Header mit jedem Response übertragen werden. Diese schaltet man im TypoScript-Setup wie folgt ein: |
| + | config.sendCacheHeaders = 1 | ||
| + | == Serverseitiges Caching über htaccess == | ||
| + | Elemente, die sich über mehrere Monate nicht oder sogar niemals ändern. Man denke dabei nur an Logos, Background-Bilder oder etwa das Favicon. Alle diese Dateien könnten bequem länger als die sie umgebende Website im Cache vorgehalten werden, sodass zumindest für wiederholende Besucher eine Performance-Verbesserung zu erwarten ist. Dafür benötigt der Webserver ein aktiviertes Modul „mod_expires“ und eine „.htaccess“-Datei, die zum Beispiel folgende Information enthält (in der Annahme, dass alle Dateien im Verzeichnis „fileadmin/website/pics/“ länger im Cache gehalten werden können): | ||
| + | <pre> | ||
| + | <LocationMatch "/fileadmin/website/pics/"> | ||
| + | <IfModule mod_expires.c> | ||
| + | ExpiresActive on | ||
| + | ExpiresDefault "access plus 6 months" | ||
| + | ExpiresByType image/gif "access plus 6 months" | ||
| + | ExpiresByType image/png "access plus 6 months" | ||
| + | ExpiresByType text/css "access plus 6 months" | ||
| + | ExpiresByType application/x-javascript "access plus 6 months" | ||
| + | ExpiresByType text/javascript "access plus 6 months" | ||
| + | ExpiresByType image/jpeg "access plus 6 months" | ||
| + | </IfModule> | ||
| + | </LocationMatch> | ||
| + | </pre> | ||
| + | == Static File Cache == | ||
| + | Es gibt Extensions um Seiten statisch abzuspeichern. Wenn eine statische VErsion existiert, wird diese angezeigt. Bietet sich also dann an, wenn auf Seiten keine dynamischen Inhalte sind. | ||
| + | |||
| + | „nc_staticfilecache“ (oder etwa „fl_staticfilecache“) | ||
| + | |||
| + | Keine Conditions möglich. Serverseitig muss „mod_rewrite“ und „mod_expires“ vorhanden sein. | ||
== Maßnahmen bei eigenen Servern == | == Maßnahmen bei eigenen Servern == | ||
| Zeile 86: | Zeile 122: | ||
table_cache = 256 | table_cache = 256 | ||
key_buffer_size = 64M | key_buffer_size = 64M | ||
| + | </pre> | ||
| + | |||
| + | == TYPO3 Caching Framework == | ||
| + | Lagert Seiten ins Filesystem oder in den Hauptspeicher aus. | ||
| + | <pre> | ||
| + | $TYPO3_CONF_VARS['SYS']['caching']['cacheBackendAssignments'] = array( | ||
| + | 'cache_hash' => array( | ||
| + | 'backend' => 't3lib_cache_backend_File', | ||
| + | 'options' => array( | ||
| + | ) | ||
| + | ), | ||
| + | 'cache_pages' => array( | ||
| + | 'backend' => 't3lib_cache_backend_Memcached', | ||
| + | 'options' => array( | ||
| + | 'servers' => array('localhost:11211'), | ||
| + | ) | ||
| + | ), | ||
| + | 'cache_pagesection' => array( | ||
| + | 'backend' => 't3lib_cache_backend_Db', | ||
| + | 'options' => array( | ||
| + | 'cacheTable' => 'cache_pagesection', | ||
| + | ) | ||
| + | ) | ||
| + | ); | ||
| + | |||
</pre> | </pre> | ||
Aktuelle Version vom 19. Oktober 2017, 08:31 Uhr
http://t3n.de/magazin/23-tipps-tricks-schnelleres-typo3-typo3-turbo-edition-225282/3/
TYPO3 ist leider nicht besonders Performant im Vergleich vieler CMS. Aber man kann viel machen um das zu verbessern. Auf der anderen Seite MUSS man auch aufpassen, das es keine Performance Killer in der Installation gibt. Die Auswirkungen sind extrem z.B. wenn nicht gecachet wird.
Performance und Serverlast testen[Bearbeiten]
einfache Tools[Bearbeiten]
- Rootkonsole: uptime (zeigt Serverauslastung an)
- ApacheBench (simuliert Zugriffe ab -n 100 -c 10 http://www.IhreDomain.de/“. Dies simuliert 100 Zugriffe, davon jeweils 10 parallel );
- YSlow Plugin für FF oder ähnliches
- Google Webdeveloper Tools für den Check der Seite direkt (Requests, Bilder...)
Performance Killer Faktoren[Bearbeiten]
- USER_INT Objekte verhindern Browserseitiges Caching
- indexed search
Fehler finden[Bearbeiten]
Parsetime und Cachezustand von Seiten im Quelltext anzeigen: localconf.php (in /typo3conf)
$TYPO3_CONF_VARS['FE']['debug'] = '1';
Datenbank[Bearbeiten]
Oft ein Engpass wenn es Slow Queries gibt. Die Server begrenzen die Zugriffe meist auf 25-35 parallel. Wenn man einmal an die Grenze kommt schaukelt sich das ganz schnell hoch. Was ist wichtig.
Alles utf-8 ?[Bearbeiten]
- Auch die Datenbank selbst sollte auf utf-8 stehen, nicht nur die Tabellen (CREATE DATABASE DEFAULT CHARACTER SET uft8)
- Zur Vorsicht kann man TYPO3 zwingen: Install Tool:
[BE][forceCharset] = 'utf-8'
- PHP zwingen nicht intern in ISO-8859-1 umzuwandeln (und zurück)
[SYS][setDBinit] ='SET NAMES utf8; SET SESSION character_set_server=utf8'; SET CHARACTER_SET utf8;
Todo check ob SET SESSION character_set_server=utf8'; SET CHARACTER_SET utf8; das gleiche ist es gibt Angaben mit dem einen oder dem anderen
Keine Permanente Datenbankverbindung[Bearbeiten]
Ist leider per default gesetzt. Also:
[SYS][no_pconnect] =1
setzen
Komprimierte Seitenübertragung einschalten[Bearbeiten]
[BE][compressionLevel] = 5 und [FE][compressionLevel] = 5
Generierung der Seiten benötigt mehr Zeit, dafür schnellere Übertragung. Gut wenn das Caching funktioniert. Benötigt zlib auf dem Server (ist normalerweise dabei)
Extensions prüfen[Bearbeiten]
Unbenutzte Extensions entfernen[Bearbeiten]
Auch wenn sie nicht verwendet werden benötigen nicht genutzte Extensions wertvolle Rechenzeit. Es müssen Klassen geladen und initialisiert oder statische Templates geladen werden, die man gar nicht benötigt. Extensions können im Extension-Manager im Bereich „Install Extensions“ gelöscht werden, indem man auf den Namen der Extension klickt, oben aus dem Pulldown-Menü den Eintrag „Backup/Delete“ wählt und anschießend auf den Link „DELETE EXTENSION FROM SERVER“ klickt.
Indexed Search[Bearbeiten]
„indexed_search“ hat einen erheblichen Nachteil. Durch die Verwendung der Extensions sinkt die Performance bei steigenden Seitenzahlen nahezu exponentiell.
Will man den selben (und sogar noch einen viel mächtigeren) Leistungsumfang verwenden, kommt man an „Apache Solr“ [3] nicht mehr vorbei. Wem ein geringerer Leistungsumfang reicht, kann „mnogosearch“ oder „joh_advbesearch“ verwenden.
HTML Kommentare[Bearbeiten]
css_styled_content Kommentare entfernen
config.disablePrefixComment = 1 lib.stdheader.5.prefixComment > lib.stdheader.stdWrap.prefixComment > tt_content.stdWrap.prefixComment >
Skripte und Styles[Bearbeiten]
Mergen[Bearbeiten]
Zunächst werden CSS- und JavaScript-Dateien verkleinert, indem Whitespaces entfernt und Variablennamen gekürzt werden. Dann werden alle auszuliefernden CSS- und JavaScript-Dateien jeweils zu einer einzigen Datei zusammengefasst und anschließend noch komprimiert.
Das kann TYPO3 von Haus aus
Inline-Styles und JS auslagern[Bearbeiten]
config.removeDefaultJS = external config.inlineStyle2TempFile = 1
CSS Sprites[Bearbeiten]
Bei vielen Grafiken spart das Zugriffe
Objekte die Caching verhindern vermeiden[Bearbeiten]
Wann immer es geht, sollte man auf den Einsatz von „TypoScript _INT“-Objekten (also „USER_INT“ und „COA_INT“) verzichten.
User intelligent verwalten[Bearbeiten]
Am Ende möglichst wenige – wirklich unterscheidbare – Benutzergruppen zu erhalten. Denn für jede Benutzergruppen-Kombination wird eine Kopie der Seite im Cache vorgehalten. Das sind bei fünf Benutzergruppen bereits 32 verschiedene Kombinationen (25) und damit eben 32 Einträge in der Cache-Tabelle.
Conditions[Bearbeiten]
Nur dort einsetzen wo man sie braucht. Beispiel den Marker „###DATUM###“ mit dem aktuellen Datum füllen will), so muss man darauf achten, dass die Condition auch wirklich nur auf diese eine Seite anschlägt und nicht etwa noch auf deren Unterseiten
Browser Caching[Bearbeiten]
Weiß dieser etwa, dass sich die Seite überhaupt nicht verändert hat, muss er diese nicht extra anfordern und spart somit wertvolle Übertragungszeit. Dafür muss dem Browser aber erst mitgeteilt werden, wie lange die Seite im Cache vorgehalten werden soll. Dafür werden so genannte Cache-Header verwendet, die per HTTP-Header mit jedem Response übertragen werden. Diese schaltet man im TypoScript-Setup wie folgt ein:
config.sendCacheHeaders = 1
Serverseitiges Caching über htaccess[Bearbeiten]
Elemente, die sich über mehrere Monate nicht oder sogar niemals ändern. Man denke dabei nur an Logos, Background-Bilder oder etwa das Favicon. Alle diese Dateien könnten bequem länger als die sie umgebende Website im Cache vorgehalten werden, sodass zumindest für wiederholende Besucher eine Performance-Verbesserung zu erwarten ist. Dafür benötigt der Webserver ein aktiviertes Modul „mod_expires“ und eine „.htaccess“-Datei, die zum Beispiel folgende Information enthält (in der Annahme, dass alle Dateien im Verzeichnis „fileadmin/website/pics/“ länger im Cache gehalten werden können):
<LocationMatch "/fileadmin/website/pics/"> <IfModule mod_expires.c> ExpiresActive on ExpiresDefault "access plus 6 months" ExpiresByType image/gif "access plus 6 months" ExpiresByType image/png "access plus 6 months" ExpiresByType text/css "access plus 6 months" ExpiresByType application/x-javascript "access plus 6 months" ExpiresByType text/javascript "access plus 6 months" ExpiresByType image/jpeg "access plus 6 months" </IfModule> </LocationMatch>
Static File Cache[Bearbeiten]
Es gibt Extensions um Seiten statisch abzuspeichern. Wenn eine statische VErsion existiert, wird diese angezeigt. Bietet sich also dann an, wenn auf Seiten keine dynamischen Inhalte sind.
„nc_staticfilecache“ (oder etwa „fl_staticfilecache“)
Keine Conditions möglich. Serverseitig muss „mod_rewrite“ und „mod_expires“ vorhanden sein.
Maßnahmen bei eigenen Servern[Bearbeiten]
PHP Beschleuniger[Bearbeiten]
- PHP Beschleuniger (z.B. eAccelerator)
t3p_scalable[Bearbeiten]
MySQL-Replikation (in der schreibende und lesende Zugriffe auf die Datenbank getrennt und somit optimiert werden) aufgebaut als auch Memcached verwendet werden. Memcached ist ein unter der BSD-Lizenz veröffentlichter Cache-Server zum allgemeinen Hinterlegen und Abholen von Daten aus dem Arbeitsspeicher. Dieser ist erheblich schneller als ein Zugriff des Caches über die Datenbank oder das File-System.
mySQL Tuning[Bearbeiten]
Erweiterte Optionen in my.cnf
max_connections = 400 #log-bin=mysql-bin query_cache_limit = 2M query_cache_size = 64M query_cache_type = 1 table_cache = 256 key_buffer_size = 64M
TYPO3 Caching Framework[Bearbeiten]
Lagert Seiten ins Filesystem oder in den Hauptspeicher aus.
$TYPO3_CONF_VARS['SYS']['caching']['cacheBackendAssignments'] = array(
'cache_hash' => array(
'backend' => 't3lib_cache_backend_File',
'options' => array(
)
),
'cache_pages' => array(
'backend' => 't3lib_cache_backend_Memcached',
'options' => array(
'servers' => array('localhost:11211'),
)
),
'cache_pagesection' => array(
'backend' => 't3lib_cache_backend_Db',
'options' => array(
'cacheTable' => 'cache_pagesection',
)
)
);
Static File Cache[Bearbeiten]
Typo3 erzeugt trotz Caching jedesmal einige Datenbank Anfragen
- früher fl_staticfilecache
- Problem -> kein idealer Code (x-classes, looping constructions), muß von Hand angestoßen werden, Modul
- Gut -> über mod_rewrite um zu entscheiden ob statisch oder dynamisch (kein php, schnell)
- wir müssen Cache Headers senden -> deshalb berauchen wir Seiten in Filesystem ?
Wir müssen Headers senden.
Rewrite Conditions:
Browser Cache[Bearbeiten]
Typo3 den Browser mittels Header Information anweisen die Seite zu Cachen. config.sendCacheHeaders = 1
Die Cache Headers werden von Typo3 gesendet, wenn bestimmte Bedingungen erfüllt sind:
ToDo...
Server und Datenbank optimieren[Bearbeiten]
http://wiki.typo3.org/index.php/Performance_tuning#Webserver_proxy_caching_or_static_file_caching
==
Typo3 - Welche Datenbanktabellen können gelöscht werden ?[Bearbeiten]
(aus dem Forum...)
The answer more or less confirmed what I had listed myself in the german list. Thread in german list has the following Subject
- [Typo3-german] Restore: ueberfluessige/unwichtige Tabellen*
Nice tip also to get around timeout when restoring database via PhpMyAdmin. --> *More Infos: * http://www.ozerov.de/bigdump
- So you don't have to look (here the german answer):*
Alle Tabellen mit *cache_** kannst du ignorieren (solange die Tabellen an sich auf Maschine B vorhanden sind.
- Sys_log *ist das Interne Logging von Typo3.
Zum Aufspüren von fehlern ganz praktisch - deine Entscheidung, ob du das mitnehmen willst.
- Sys_history *ist die Änderungs-Verlauf der Objekte in Typo3 - auch hier
wieder deine Entscheidung
- Sys_stat *ist der übliche Killer.
die Ext lohnt sich meiner Meinung nach nur dann, wenn man keinen Zugriff auf Webserver Logs hat. Oder der Kunde einfache Statistiken direkt im BE sehen möchte. Hierzu kann ich nur empfehlen, einmal pro Monat einen CRON Job laufen zu lassen (oder von Hand) der alle Datensätze exportiert, die älter als 2 Monate sind (mit mysqldump --where) und danach die exportierten Daten zu löschen. sys_stat wächst schnell auf zig Millionen Records an und lähmt damit die DB. Wir hatten vor 3 Wochen den Fall, dass sys_stat so groß war, dass wir es nicht mehr selected konnten, noch exportieren oder gar löschen. Blieb also nur der Weg "DB runterfahren, Datendatei löschen, DB hochfahren"