serverperformance - caching - proxy
| Autor | Nachricht |
|---|---|
|
Verfasst am: 30. 05. 2007 [23:11]
|
|
|
enobe.de
Themenersteller
Dabei seit: 08.02.2007
Beiträge: 115
|
Arbeite seit 2004 mit Typo. Habe jetzt ein Projekt, welches von 200 besuchern täglich mal soeben für einen Tag von 3000 Besuchern angesteuert wurde. Tolle sache, aber der Server hats nicht mitgemacht. jetzt wurde ich vom Administartor gebeten mir Geadnken zur Optimierung zu machen: enableContentLengthHeader = 1 sendCacheHeaders = 1 um eventuell einen Proxy auf unserem Server für das Cachen der Seiten (für die es nötig/möglich ist) zu nutzen. Ich selbst bin noch nicht der Meinung, dass diese laufende Typo3-Umgebung mit ihren Einstellungen keine mit 3000 Besuchern resultierende 12.000 Zugriffe bewältigen könnte. (eigener DEBIAN-Server, und kaum mehr als 'tt_news' an Extensions in Benutzung) Suche jetzt nach möglichen Erfahrungswerten und Tipps rund um die Einschätzungen von serverseitiger Performance und evtl. unklug eingesetzten Extensions, um die richtige Wahl für Optimierungsarbeiten treffen zu können. Mir ist dabei aufgefallen, dass Typo3 v4.0.6 immerhin (Seiten ohne Content,Styling und Plugins etc.) von Hause aus gecachte Seiten (cache_pages) standartmäßig mit der Ausführung von insgesamt 11 Datenbankabfragen (SELECTquery -> t3lib/class.t3lib_db.php) ausliefert. Kommen eigene TScripts mit Conditions oder Plugins (USER_INTS) hinzu, summiert sich die Anzahl dieser Datenbankabfragen auf über 20 pro gecachte Seite, was selbsterklärend die performance beeinflusst. Gibts da Tools, um das genauer zu prüfen? Wo fange ich an? Wie hoch ist die wahrscheinlichkeit, das die Typo3 Umgebung sich selbst behindert (bei 3000 Besuchern)? thx, Jörg Kummer |
  |
|
|
Verfasst am: 25. 06. 2007 [17:24]
|
|
|
Sven.Krause
Dabei seit: 16.08.2005
Beiträge: 5
|
Selbes Thema auf unserer Webseite. Bist du hier mittlerweile weitergekommen? Gruß Sven |
|
|
|
Verfasst am: 25. 06. 2007 [18:19]
|
|
|
steffenk
Moderator
Dabei seit: 22.09.2005
Beiträge: 4839
|
schau Dir mal den letzten Podcast an  http://castor.t3o.punkt.de/files/podkast_static.m4v |
|
|
|
Verfasst am: 26. 06. 2007 [10:50]
|
|
|
enobe.de
Themenersteller
Dabei seit: 08.02.2007
Beiträge: 115
|
ich habe lange gebraucht, um mal so in allen ecken von unserer installation herumzukramen. nachdem andere mitarbeiter in der selben zeit noch weitere funktionen und performance beeinträchtigende features implementierten, mußte ich mich dazu entschliessen, die Lösung über die installation eines eigenen PROXY-Servers zu suchen. dafür sind Proxies schließlich da, und typo3 hat alles, um richtige Aussagen zum Cache jeder Seite hinzuzufügen (sendCacheHeaders). Muß die Typo3-umgebung nur noch in vielen Teilen dazu angepasst werden, bzw. konzeptionell überdacht werden, da die Konfiguration 'sendCacheHeaders' einige Bedingungen stellt. Ich konnte den Einsatz des Proxies jedoch selber noch nicht testen, da unser Hostmaster, plötzlich und leider nicht mehr versteht was mit Cache und Proxy zu tun ist. |
|
|
|
Verfasst am: 26. 06. 2007 [11:49]
|
|
|
mrmiagi1984
Dabei seit: 03.09.2004
Beiträge: 66
|
link http://www.admin-wissen.de/tutorials/eigene-tutorials/webentwicklung/typo3-workshop/fortgeschrittene-themen/typo3-seo/perfomance-tuning/ Wer nicht vom Weg abkommt bleibt auf der Strecke
|
|
|
|
Verfasst am: 01. 12. 2008 [13:21]
|
|
|
enobe.de
Themenersteller
Dabei seit: 08.02.2007
Beiträge: 115
|
Und an dieser Stelle kurz meine Erfahrung mit dem Einsatz eines ProxyServers: Ganz wichtig hierbei, dass das Caching von Seiten durch TYPO3 aktiviert ist. TYPOSCRIPT config.cache_period = 3600 #cache_period (86400=24h,3600=1h,900=15min,300=5min) In diesem Beispiel gilt 1 Stunde global für alle Seiten, wenn nicht für einzelne Seiten andere Angaben gesetzt werden. Damit die sogenannten Cache-Control headers bei jeder Anfrage durch einen Browser richtig gesendet werden, diese Einstellung: TYPOSCRIPT config.sendCacheHeaders = 1 # config.enableContentLengthHeader = 1 'enableContentLengthHeader' habe ich nicht gesetzt. Dadurch wurde die Auslieferung der Seiten durch den Proxy für die angegebenen Zeiträume (bis 'Expires') übernommen, und entlastete die Prozesse des Webservers erheblich. Jetzt blieb folgendes Problem zurück: Der InternetExplorer interpretierte die Cache-Control headers anders als erwartet. Last-Modified: Mon, 23 Jul 2007 11:54:54 GMT Expires: Mon, 23 Jul 2007 11:58:41 GMT Cache-Control: max-age=227 Die Angabe für 'Last-Modified' wird vom IE höher bewertet als 'Expires', womit es kein Grund gab, das dieser Browser überhaupt eine aktuellerere Version der Seite vom Server lädt. ('Last-Modiefied' = Zeitpunkt der letzten realen Änderung der Seite in TYPO3) Der IE ignorierte 'Expires' und umging somit sowohl Proxy als auch TYPO3, und bediente sich seines eigenen Caches, auf den ich die Kontrolle verlor. Der IE-Browser bekam also keine aktuellen Inhalte mehr aus dynamisch generierten Inhalts-Elementen. Deshalb habe ich beschlossen, mit dem Senden der Cache-Control headers die Angabe 'Last-Modified' wegzulassen, was den gewünschten Erfolg lieferte. Dazu habe ich aus den TYPO3 internen Dateien folgende Änderungen vorgenommen, bzw folgende Zeilen auskommentiert: 1. .../typo3/sysext/cms/tslib/class.tslib_fe.php * class tslib_fe; Line 2937; function sendCacheHeaders() PHP # 'Last-Modified: '.gmdate('D, d M Y H:i:s T', $this->register['SYS_LASTCHANGED']), // uncommented2. .../typo3/t3lib/class.t3lib_userauth.php * class.t3lib_userauth; Line 312; function start() PHP # header('Last-Modified: ' . gmdate('D, d M Y H:i:s') . ' GMT'); // uncommented |
|
|