[TYPO3-german] Verhalten von Seitenparsing bei Einbindung von Extension

David Bruchmann david at bruchmann-web.de
Wed Apr 15 20:54:34 CEST 2009


----- Ursprüngliche Nachricht -----
Von:        bernd wilke <x00nsji02 at sneakemail.com>
Gesendet:   Mittwoch, 15. April 2009 20:11:21
An:         typo3-german at lists.netfielders.de
CC:
Betreff:    Re: [TYPO3-german] Verhalten von Seitenparsing bei 
Einbindung von Extension
> Am Wed, 15 Apr 2009 15:35:58 +0200 schrieb David Bruchmann:
> 
>> ----- Ursprüngliche Nachricht -----
>> Von:        Christian Wolff <chris at connye.com> Gesendet:   Mittwoch, 15.
>> April 2009 15:09:13 An:         typo3-german at lists.netfielders.de CC:
>> Betreff:    Re: [TYPO3-german] Verhalten von Seitenparsing bei
>> Einbindung von Extension
>>> David Bruchmann schrieb:
>>>> Hallo Zusammen,
>>>>
>>>> in einer Seite habe ich eine Extension eingebunden, die recht viel
>>>> Datenbankabfragen braucht und auch recht speicherhungrig ist.
>>>>
>>>> Die Extension selbst wird aber nur auf Unterseiten eingebunden, die
>>>> Unterhalb einer entsprechenden Übersichtsseite sind:
>>>>
>>>> - Übersichtsseite
>>>>    - a
>>>>    - b
>>>>    - c
>>>>
>>>> Die Übersichtsseite ist weitgehend leer, lediglich die Unterseiten
>>>> tauchen in der Navi auf.
>>>> TYPO3 braucht jetzt extrem lange beim Generieren der Übersichtsseite -
>>>> meine Vermutung ist, daß dort schon Ergebnisse der Extension abgefragt
>>>> werden, was mir sinnlos erscheint bzw. nicht gewollt ist, da die
>>>> Ergebnisse dort nicht relevant sind.
>>>>
>>>> Hat jemand diesbezüglich schon mal näherer Untersuchungen
>>>> durchgeführt?
>>>>
>>>> Danke
>>>> David
>>> Hallo David,
>>> ich nehme an bei der exttension handelt es sich um ein plugin als
>>> content element. dann sollte die extension die übersichts seite
>>> eigendlich nicht beeinflussen.
>>>
>>> sonst müste Typo3 ja immer alle Conten elemente aller seiten rendern
>>> wenn man auf die index seite einer typo3 installation geht. (und das
>>> ist definitiv nicht so)
>>>
>>> gibt natürlich auch extensions die sich in generelle aufrufe einbinden
>>> z.b realURL da es ja jeden typoLink umschreiben will. am ende hängt
>>> dann davon ab was de extension entwickler gemacht hat.
>>>
>>> gruss chris
>>>
>>>
>> Hallo Chris,
>>
>> ja, es ist ein Contentelement.
>> Deinen Eindruck hatte ich eigentlich auch bisher, aber teilweise
>> brauchte die Übersichtsseite schon ungewöhnlich lang. Es kann auch sein,
>> daß der Server generell überlastet war und die Seite deswegen so lange
>> brauchte.
>> Jedenfalls habe ich für genau solche Situationen in der Extension das
>> Caching aktiviert - leider braucht es lange, bis dann der Cache für alle
>> Unterseiten erzeugt ist - und bloß nicht den Cache löschen ;-)
> 
> ohne Angabe um welche Extension es sich handelt ist das ein Stochern im 
> Nebel über grundsätzliche Fehler.
> 
> ein solcher Fehler könnte sein, dass die Typoscript-Konfiguration der 
> Extension auf jeder Seite eingebunden ist und so einen enormen Overhead 
> beim Rendern der Seite produziert. Schlimmer noch könnten Einbindungen 
> von CSS und Javascript sein, die auf deinen übergeordneten Seiten absolut 
> überflüssig sind.
> Wichtig wäre eine Analyse wo die ganze Zeit benötigt wird:
> - beim Aufbau des HTML, also innerhalb des PHP
> - beim Aufbau der Bilder, ImageMagik braucht nun mal lange um 30 Bilder 
> von ganz groß (10M-Pixel) auf Thumnail (200x150) zu skalieren
> - beim Laden der Seite (zu viele Elemente? unsichtbare Elemente (CSS)? 
> Bilder in Übergröße, die aber nur minimal angezeigt werden? falsche 
> Apache-Konfiguration?
> - beim Aufbau der Seite im Browser, ggfls noch eine Seitenmodifikation 
> durch Javascript?
> 
> 
> bernd

Hallo Bernd,

die Extension habe ich bisher nicht veröffentlicht, aber sie ist auf der 
Seite 
http://www.bruchmann-web.de/zh-hk/support/windows/bluescreen/0x00000004/ 
sichtbar.

Die enorme Last wird bei Seiten erzeugt, die viele Datensätze haben, da 
die Sortierfunktion Datensätze aller Sprachen einliest, um eine interne 
Language-Fallback zu gewährleisten. Ich habe dort schon etwas verändert 
aber muß dort noch mal ran, um die Last zu reduzieren. Ein Beispiel für 
so eine Seite ist 
http://www.bruchmann-web.de/zh-hk/support/windows/bluescreen/0x0000000a 
- momentan wird sie vom Server noch nicht verarbeitet.
Die meisten anderen Unterseiten sind mittlerweile gecached - ich hatte 
die Seiten-Navi überarbeitet, so daß der no_cache-Parameter nicht in den 
Flaggen-Links erscheint. (Pagebrowser fehlt noch). Wenn alles drin ist 
werden weitere Seiten wieder aktiviert, die ich wegen Überlastung vom 
Netz nehmen mußte.

Ist aber eigentlich auch egal - das sind ja alles Unterseiten. Die Frage 
war, ob TYPO3 eventuell Extensions schon im darübeliegenden Level einliest.
- CSS ist nur sehr wenig eingebunden und JS gar nicht.
- Bilder sind nur auf den Unterseiten verlinkt und werden nicht mit 
ImageMagick bearbeitet.
- Bei der Apache-Konfiguration wüßte ich spontan nicht, wo ich 
problemspezifiscch dran drehen könnte / müßte. Ich habe durch Eintrag in 
der globalen Index.php das Timeout etwas hochgedreht, aber wenn MySQL 
streikt, nützt das gar nichts. Die Belastung auf Seiten ohne meine 
Erweiterung ist allerdings generell relativ niedrig sowohl für PHP als 
auch für MySQL.
- Bei der Analyse, wo wieviel Zeit benötigt wird, bräuchte ich einen 
Tipp , ich wüßte nicht wie ich so etwas feststellen kann.

Verwunderlich ist, daß 
http://www.bruchmann-web.de/zh-hk/support/windows/bluescreen bei der 
ersten Generierung sehr lange brauchte.

Wer die Seite ohne Cache aufrufen will:
http://www.bruchmann-web.de/[SPRACHKÜRZEL]/no-cache/...

Viele Grüße
David




More information about the TYPO3-german mailing list