> 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
_______________________________________________ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
