Typo3 - Performance optimieren
Performance und Serverlast testen
einfache Tools
Rootkonsole: uptime (zeigt Serverauslastung an)
Performance Killer Faktoren
- USER_INT Objekte verhindern Browserseitiges Caching
- indexed search
Fehler finden
Parsetime und Cachezustand von Seiten im Quelltext anzeigen: localconf.php (in /typo3conf)
$TYPO3_CONF_VARS['FE']['debug'] = '1';
Static File Cache
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
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
http://wiki.typo3.org/index.php/Performance_tuning#Webserver_proxy_caching_or_static_file_caching
==
Typo3 - Welche Datenbanktabellen können gelöscht werden ?
(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"
