[TYPO3-german] Fluid Performance Frage

[Dr. Dieter Porth]

Hallo Michael,


Am 12.03.2016 um 08:51 schrieb Michael Kasten:
> Hallo Dieter,
>
> Am 11.03.2016 um 23:36 schrieb Dr. Dieter Porth:
>> Hallo Michael,
>>
>> die Fluid-Variablen habe ich in meinen letzten Aufsetzungen nie benutzt.
> Dann wird es aber schwer die Frage zu beantworten :)
Stimmt. Aber vor drei Jahren, als ich mit TYPO3 anfing, habe ich sie 
benutzt. ich empfand sie aber als unübersichtlich.
Es ist aber einfach schöner, wenn man das HTML möglichst nur im Template 
findet und möglichst wenig HTML ins TypoScript auslagert.
(Insbesondere aber auch, weil TypoScript auch nicht sehr debug 
freundlich ist. ;-) )

>> Zur Performance:  Ich rechne über'm dicken Daumen geschätzt mit 80 bis 150ms pro Partialaufruf.
>> Solange die Zahl der Partials pro Seite  gut unter 50 bleibt, ziehe ich den systematischen Aufbau
>> der Fluid-Templates dem TypoScript-Gefrickel vor, selbst wenn das Typoscript um einiges schneller
>> ist.
> Hast du in Bezug auf die Zeiten entsprechende Erfahrungswerte gemacht oder gibt es dazu irgendwelche
> Quellen?
Ja. Ich hatte mal eine längtere größere Liste ausgegeben, die viele 
Partials (über 500) benutzte, welche ihrereseits einige Viewhelper noch 
nutzten. Daher die Erfahrungswerte von 80-150ms.
  Explizite systematische Messungen und standardisierte Benchmark-Tests 
habe ich allerdings nie gemacht.
> Droht die Zahl der Partialaufrufe pro Seitenaufruf auf über 50 zu steigen, ist zu überlegen, ob
>> man nicht mit einem eigenen Service die Daten direkter zusammenstellt oder ob man nicht eine
>> Extension mit geeigneten Datenstrukturen anlegt. In diesem Fall ist eigenständiges Programmieren
>> meist performanter als die TypoScript-Lösung
> Ich denke das kommt auf den Anwendungsfall an, bei 50 Partials je Seite wäre ich wahrscheinlich eher
> geneigt meine Templatestruktur einzudampfen. Wenn ich mal 100ms je Partial bei durchschnittliche 30
> Partials annehme (ich müsste mal durchtesten was in unseren Projekten da so im Schnitt verwendet
> wird) dann habe ich ja schon stattliche 3 Sekunden nur für das Templating bei einer Seite die nicht
> aus dem Cache kommt, da kann man ja mal drüber reden.
Da stimme ich dir zu. 50 Partials kommen zum Beispiel schnell zustande, 
wenn man Schleifen nutzt.
>> Bei der Wahl zwischen TypoScript und Fluid-Templates ist die Frage nach der Performance eher
>> kontraproduktiv. Wichtigere Kriterien sind meines Erachtens Übersichtlichkeit, Lesbarkeit und
>> natürliche Datenstrukturen
> Deine Kriterien setze ich einfach mal bei einer Projektumsetzung voraus, beantworten aber leider
> auch nicht die Frage ob es Differenzen zwischen den beiden hinterfragen Einbindungsmethoden gibt und
> ich verstehe auch nicht warum eine Frage nach der Performance als kontraproduktiv zu werten ist?
Sie ist nicht kontraproduktiv. Ich würde das Kriterium nur nicht an die 
erste Stelle setzen. Wenn Performance kritisch wird, dann gibt es viele 
andere Stellschrauben, an welchen man zuerst drehen sollte, denke ich. 
Man kann die Infrastruktur optimieren (Verteilter Server, Image-Server, 
Varnisch, ...) oder man speckt das template ab. Mehr Javascript auf der 
Seite (AJAX, dynamische Layouts + JSON, ...)

> Offensichtlich war meine Fragestellung doch sehr unklar, mir geht es ja nicht um die Frage wo ich
> Funktionalitäten umsetze (also in deinem Beispiel ob ich das Menü in TS erstelle und anschließend
> einbinde oder alternativ direkt ein Fluidmenü benutze)
>
> Sondern ob es Erfahrungen gibt hinsichtlich von Performanceunterschieden bei der Verwendung von
> Fluidtemplate variables oder von TS lib Objekten innerhalb von Fluid.
Im obigen Project habe ich dann die Datensätze (500) per Controller 
direkt in eine Variable schreiben lassen und diese dann im 
Extensiontemplate per f-Viewhelper gerendert. Dies kommt der Zuweisung 
im Fluid-Template sehr nahe und war damals ein echter Performance-Sprung.

Folgendes zur Überlegung:
Nach meinen Erfahrungen und meinem Bild im Kopf ist das Ausgabereultat 
eine Scriptes in TypoScript immer ein String. Die Übergabe eine Strings 
an eine Template-Variable ist ein Zuweisungsvorgang
Jeder Viewhelper ist dagegen als Klasse definiert. Die Nutzung von 
Klassen bringt im Vergleich zu einer Zuweiisung immer einen 
bürokratischen Overhead mit sich. (Klasseninstanzierung, 
Methodenaufrufe, ...).

Auszug aus einer Cache-Datei aus dem typo3temp-Ordner. (Ich vermute, 
dass $currentVariableContainer auch die zugewiesenen Template-Variablen 
enthalten könnte - habe es aber nicht getestet.)

/**
  * Main Render function
  */
public function 
render(\TYPO3\CMS\Fluid\Core\Rendering\RenderingContextInterface 
$renderingContext) {
$self = $this;
$currentVariableContainer = 
$renderingContext->getTemplateVariableContainer();

$output0 = '';
// Rendering ViewHelper 
TYPO3\CMS\Fluid\ViewHelpers\Format\HtmlspecialcharsViewHelper
$arguments1 = array();
$arguments1['value'] = 
\TYPO3\CMS\Fluid\Core\Parser\SyntaxTree\ObjectAccessorNode::getPropertyPath($currentVariableContainer->getOrNull('menu'), 
'label', $renderingContext);
$arguments1['keepQuotes'] = false;
$arguments1['encoding'] = NULL;
$arguments1['doubleEncode'] = true;
$renderChildrenClosure2 = function() {return NULL;};
$value3 = ($arguments1['value'] !== NULL ? $arguments1['value'] : 
$renderChildrenClosure2());

$output0 .= (!is_string($value3) ? $value3 : htmlspecialchars($value3, 
($arguments1['keepQuotes'] ? ENT_NOQUOTES : ENT_COMPAT), 
($arguments1['encoding'] !== NULL ? $arguments1['encoding'] : 
\TYPO3\CMS\Fluid\Core\Compiler\AbstractCompiledTemplate::resolveDefaultEncoding()), 
$arguments1['doubleEncode']));

$output0 .= ' <select class="form-control t3-js-jumpMenuBox" name="';
// Rendering ViewHelper 
TYPO3\CMS\Fluid\ViewHelpers\Format\HtmlspecialcharsViewHelper
...

Mit besten Grüßen
     Dieter