[TYPO3-german] erhebliche Performanceprobleme => gefunden, Lösung gesucht ;-)

[Bernd Wilke]

On Tue, 7 Aug 2007 18:56:11 +0200, Christoph Kuhn wrote
with subject "Re: [TYPO3-german] erhebliche Performanceprobleme =>
gefunden, Lösung gesucht ;-)":

> Am Dienstag, 7. August 2007 15:21 schrieb Marco Peemöller:
> > Christoph Kuhn schrieb:
> > > Die gute Installation ist eigentlich eine Kopie der diesigen, ausser dass
> > > sie ein anderes Template verwendet, keine Multidomain ist.
> > >
> > > Ideen wo anfangen?
> >
> > Ist vielleicht bei der einen Domain no_cache gesetzt? Oder ist in der
> > langsameren Domain zusätzlich eine Extension installiert? Das wären
> > jetzt meine ersten Ansatzpunkte.
> 
> Nein, kein no_cache. Es hat einzelne zusätzliche Extensions, zB cal.
> 
> Ich bin jetzt aber auf die Spur gekommen:
> 
> Nach Anleitung von http://ug.typo3-nrw.de/png_transparenz.html habe ich mir 
> ein Menü zusammengebaut, welches transparente PNG's enthält.

es gibt dafür inzwischen einfachere Lösungen. Ich hab sie unter
http://pi-phi.de/t3v4/55.html zusammen getragen.

 
> Das Dumme ist nur: Typo3 korrigiert die Pfade nicht!!!

TYPO3 oder dein Browser?

normalerweise ist es ein Problem des Browsers.
Dazu muss man verstehen wie Pfade im Browser interpretiert werden.

wenn ich in einer CSS-Datei eine Datei (mit Pfad) angebe bezieht sich das
immer auf den Pfad der CSS-Datei. Nicht viel anders in einer HTML-Datei.

Anders in einer PHP-Datei. Dort beziehen sich Pfade immer auf die
Hauptdatei, egal woher irgendwelche Includes herkommen. So muss in einer
PHP-Datei einer Extension immer so getan werden als ob man sich im
TYPO3-Root befindet, auch wenn die Extension-Datei im Verzeichnis
/typo3conf/ext/extension/pi1/ liegt.

und noch Komplizierter wir des mit RealUrl und den pseudo-Pfaden, die
dadurch aufgebaut werden. Auf einmal ist nicht mehr das
TYPO3-Root-Verzeichnis die Basis aller Dinge. :-/

Ausbrechen kann man mit zwei Möglichkeiten:
1) absolute Pfade: statt in der Datei fileadmin/css/main.css den Aufruf als
.meindiv {background-image:url(../img/bg.jpg); } schreibt man 
.meindiv {background-image:url(/fileadmin/img/bg.jpg); }
(natürlich nur sofern das TYPO3 im root deiner Domain installiert ist)

2) man setzt eine baseurl: http://de.selfhtml.org/html/kopfdaten/basis.htm
daraufhin werden alle url-Angaben relativ zu dieser Adresse angesehen. 
mögliches Problem: nicht nur Bilder und CSS, auch Seiten werden ab dort
gesucht. evtl. ist das aber nicht das root-dir von typo3.



 
> [styles.css]
> #topnav1 {
> filter:progid:DXImageTransform.Microsoft.AlphaImageLoader( 
> src='images/topnav1.png', sizingMethod='scale');
> }
> 
> Damit wird ein Bild unter 
> http://www.domain1.ch/aktueller/pfad/images/topnav1.png gesucht, und das 
> existiert da natürlich nicht. 
> Dann wird eine Fehlerseite ausgegeben... für jedes Bild einzeln...
> Bisher war mir das nie aufgefallen, da ich weit und breit kein Browser 
> rumstehen hatte, den das betreffen würde (ie5-6).
> 
> Nun müssen zwei Probleme gelöst werden: 
> 
> 1. Wenn ein Bild nicht gefunden wird (Endung gif/png/jpg/...) soll nicht die 
> Fehlerseite, sondern ein HTTP-Error oder ein entsprechendes dummy.gif 
> angezeigt werden. Dies würde dann nämlich nicht jedesmal neu geschickt...
> 
> 2. Typo muss irgendwie beigebracht werden, dass er auch die URLs in den src 
> Tags von filter anpassen muss.

hä? da verlangst du aber etwas viel. 
genauso kannst du verlangen, dass dein Telefon automatisch übersetzt, wenn
am anderen Ende jemand nicht deutsch spricht. Ja ich weiss: die ersten
Versuche dazu gibt es. aber meines Wissens nach ist das noch in den
Kinderschuhen (und man muss die Sprache vorher festlegen).

benutze doch den 3.ten Ansatz auf meiner Seite. Das ist ein automatischer
Ansatz. Allerdings hat der nichts mit TYPO3 (auf dem Server) zu tun,
sondern ist in Javascript (im Browser/Client).
 
> Die Seiten sind jetzt wieder viel schneller abrufbar. Trotzdem bleibt ein 
> fader Nachgeschmack. Wenn 20 Klicks jeweils einen html Code von 14kB abrufen 
> und dabei drei zusätzliche Objekte nicht gefunden und jeweils eine 11kB 
> Fehlerseite zurückgeschickt wird, ergibt dies rund 1MB. In den Logs sind aber 
> nur die ersten neun Klicks zu finden, danach war der Apache verklemmt und die 
> Prozesse konnten nicht normal beendet werden, sondern mussten mit kill -9 
> gekillt werden.
> 
> Wenn ich den Versuch jetzt wiederhole, so bringe ich den Load noch immer über 
> 10, der Load erholt sich aber inner weniger Minuten. 
> Ist da eher bei der Apachekonfig oder bei der Typo Konfiguration zu suchen?
> Irgendwo muss doch da noch grob der Hund drin stecken? Die notfound Seite und 
> das zugehörige realurlkonfig ist übrigens original WEC kopiert.

das Problem ist wohl wieviele und welche Prozesse laufen bei einem
Fehlzugriff? Ich vermute mal dass die Timeouts zu lange dauern bis ein
Prozess als erfolglos beendet wird. Dadurch sammeln sich die Prozesse an,
wobei jeder Resourcen kostet. und die werden dann knapp, woraufhin
vermutlich ein swapping ansetzt, was zu weiteren Prozessen und noch mehr
Diskzugriffen führt: die Resourcen werden noch knapper.

Probier es mal mit einem Windowsrechner aus:
öffne den taskmanager, so das du siehst welche prozesse wieviel Speicher
benötigen. und dann starte mal ein paar speicherhungrige Programme:
Bildbearbeitung mit richtig dicken Bildern, Textverarbeitung mit langen
Texten, Movieplayer, mp3-player, ... wenn du dann auf einmal mehr Platz
benötigst als du physikalisch im Rechner hast geht das Swappen in die
Auslagerungsdatei los. wenn du dann zwischen den Anwendungen hin und her
springst um eine zu beenden (damit wieder mehr Speicher zur Verfügung
steht) reagiert alles nur noch in Zeitlupe. erst wenn das erste Programm
beendet wurde und wieder Speicher frei wird können die anderen Programme
wieder etwas arbeiten (und sich zb. auch beenden)

Bernd

-- 
Don't ask what the TYPO3-community can do for you.
Ask what you can do for the TYPO3-community.

http://www.pi-phi.de/t3v4/cheatsheet.html