[TYPO3-german] TypoScript Verschachtelung und Performance

JoH asenau info at cybercraft.de
Tue May 11 15:15:30 CEST 2010


> Performance-Fresser, was kann man sich darunter *ungefähr* vorstellen?
> Angenommen, ich habe eine durchschnittliche Seite auf einem
> durchschnittlichem Server mit durchschnittlichen Zugriffszahlen. Mit
> Templavoila habe ich (unter 4.2) Rendering-Zeiten von 100 bis 200ms.
> Wie viel schneller wäre es ungefähr ohne TV? ~80ms bis ~150ms? Oder
> wirkt sich das gar nicht so sehr auf die Rendering-Zeit aus sondern
> eher darauf, wie viele Seiten ich je Sekunde ausliefern kann?

Es geht dabei weniger um die Performance beim Ausliefern der Seiten im
Frontend allein sondern um die Art und Weise, wie die Daten in der Datenbank
abgespeichert werden. Der gesamte Inhalt einer Seite wird über ein großes
XML Konstrukt in ein einziges Datenbank-Feld geschrieben, was sich sowohl im
Frontend als auch im Backend entsprechend auswirkt. Wenn hier von
Performance die Rede ist, dann nicht nur von Millisekunden im FE sondern
z.B. auch von Arbeitsstunden für Redakteure oder Entwickler.

Standard-Mechanismen auf Datenbank-Ebene wie z.B. colPos, sorting etc.
werden komplett ausgehebelt. Das CONTENT Objekt wird damit mehr oder weniger
unbenutzbar, weswegen TV per Default auch ausschließlich mit RECORDS
arbeitet. Zusätzliche Abfrage-Möglichkeiten, die bei CONTENT z.B. über where
oder andWhere hinzugefügt werden können, um die Ergebnismenge einzuschränken
sind dort nicht möglich. Selbst wenn man die pid eines Datensatzes kennt,
muß man dennoch die XML Struktur befragen, weil er ja auch zu den "unused
elements" gehören könnte.

Eine Abfrage auf Datenbank-Ebene wird dadurch erheblich erschwert, wenn
nicht unmöglich gemacht, da die XML Struktur eines jeden Datensatzes
einzeln(!) komplett aufgedröselt werden muß, um die einfachsten Dinge
herauszufinden. Was das für den Speicherbedarf und die Geschwindigkeit
solcher Abfragen bedeutet, dürfte klar sein. Auch hinsichtlich einer
Anbindung der Daten an andere Systeme ist TV was die interne Datenhaltung
angeht eine mittlere Katastrophe.

Wobei man anerkennen muß: Es erfüllt seinen Zweck was die
Benutzerfreundlichkeit angeht und die Performance-Einbußen halten sich in
Grenzen, je kleiner die Site und damit der Umfang der Datenbank ist.
Deswegen sind es in unserem Kundenkreis vor allem größere Ex-TV-Projekte mit
einer Anzahl an Seiten jenseits der 5-Stellen-Grenze, die Zug um Zug von TV
auf Standard-Templating "rückgebaut" werden - und zwar nicht etwa, weil wir
darauf drängen würden, sondern weil die Verantwortlichen selbst begriffen
haben, daß das "futuristic template building" nicht ganz so future proof
ist, wie man angenommen hatte.

HTH

Joey

-- 
Wenn man keine Ahnung hat: Einfach mal Fresse halten!
(If you have no clues: simply shut your gob sometimes!)
Dieter Nuhr, German comedian
Xing: http://contact.cybercraft.de
Twitter: http://twitter.com/bunnyfield
TYPO3 cookbook (2nd edition): http://www.typo3experts.com




More information about the TYPO3-german mailing list