Ich bin gerade völlig verzweifelt - der Titel beschreibt schon mein gesamtes Dilemma.
Kurzbeschreibung:
- mein Projekt enthält einen Fragebogen
- es gibt verschiedene Fragetypen - das Rendering ist teilweise in unterschiedliche Partials aufgeteilt
- mit dem Einpflegen von Fragen / Texten wurde der Aufruf immer langsamer
- insgesamt enthält der Bogen im Moment rund 580 Elemente (ein Element kann auch ein einfacher Text / eine Überschrift / ein Bild sein)
Das ist natürlich ein bisschen. Allerdings ist die Zeit, die für das Rendering gebraucht wird noch ein ganzes bisschen mehr: bis das Formular geladen ist, vergehen satte 6,2 Sekunden. Ich habe alles einmal durchgeprüft - der Löwenanteil vergeht beim Rendering mit Fluid. Die Eckdaten:
- wenn ich die Schleife im Haupttemplate rausnehme (die über die Elemente iteriert) und nur eine einfache Ausgabe machen, bin ich auf 700-800ms runter. Das ist zwar immer noch langsam, bei dieser Komplexität und da es nunmal ein Framework ist (und Doctrine involviert ist) könnte ich damit vielleicht leben.
- ich nutze das TYPO3/Media Package und damit den image-Viewhelper. Wenn ich den entferne gewinne ich ca. 200ms
- ich nutze einen eigenen If-Viewhelper, um komplexere Bedingungen zu ermöglichen, die then- und else-Viewhelper sind wieder Standard. Wenn ich den Viewhelper umschalte, so dass er keine Evaluierung macht, sondern z.B. immer mit true arbeitet, ergibt sich keine Änderung (bzw. die Zeit geht auf knapp 12 Sekunden hoch, weil noch mehr Elemente gerendert werden)
- ansonsten werden nur Fluid-Standard-Viewhelper verwendet.
Kann es sein, dass ich irgendwo was übersehe oder einen groben Fehler mache? Ich stand Fluid zwar von Anfang an aufgrund der Grundkonzepte skeptisch gegenüber, aber es kann doch unmöglich so dermaßen inperformant sein, oder?
Wenn das wirklich an Fluid liegen sollte, wäre das ein absolutes K.O.-Kriterium für Fluid (und damit auch für Flow, da mir die Zeit fehlt einen eigenen View zu schreiben).
Ich hoffe und bete, dass der Fehler irgendwo bei mir liegt und mir jemand einen Ansatz geben kann, wo ich suchen muss. Ich finde im Moment nämlich leider keinen Grund oder Ansatz...
Viele Grüße,
Christian
Ich habe schonmal wieder eine Teilantwort für mich selbst. Durch Zufall bin ich kurz nach dem Schreiben des Posts hier im Forum auf einen "Leidensgenossen" - wenn auch in Typo - gestoßen. 
#105492
Ich habe daraufhin auch mal alles in einem Partial zusammengefasst und siehe da: die Zeit, die Fluid mit dem Rendering verbringt (ich habe mir mal eine Zeitmessung in die Render-Funktion gebaut) sinkt von rund 5,6 Sekunden auf 750ms. Das ist zwar immer noch eine himmelschreiende Katastrophe, aber ebenso ein himmelweiter Unterschied.
Das relativiert mein Problem etwas, löst es aber nicht. Die Performance ist immer noch unbrauchbar. Dazu kommt jetzt noch das zweite Problem, dass die Organisation und Übersicht flöten geht, da ich keine Partials mehr beutzen kann (von Wiederverwendbarkeit mal ganz zu schweigen).
Ich bin also immer noch für jeden Tipp und Hinweis dankbar.
Viele Grüße,
Christian
Sorry, ich muss das Thema nochmal aufgreifen und etwas pushen. Wir stehen mittlerweile kurz davor einen eigenen View für Flow zu schreiben, weil die Performance in Fluid zu schlecht ist. Was uns davon abhält ist vor allem, dass Fluid ja nunmal die "native" Templating Engine von Flow, vor allem aber auch von Typo ist.
Die Erkenntnisse:
- das Projekt ist weiter gewachsen, ebenso der Fragebogen. Aufgrund der bisherigen Werte dürften wir bei einem "Partial-basierten" Rendering mittlerweile um die 10 Sekunden liegen (kann ich auch gerne nochmal testen, falls es jemanden genau interessiert)
- wenn ich Partials (weitgehend) weglasse und alles in einem Partial zusammenfasse, liege ich bei einer Renderzeit von 2,35 Sekunden
- Ich habe mir nun die Mühe gemacht, den HTML-Code 1:1 vom Objekt selbst generieren zu lassen. Das heißt, Fluid baut mir das Grundgerüst, die einzelnen Fragen rendern sich aber gewissermaßen selber. Damit bin ich auf einer Renderzeit von 1,2 Sekunden.
Schlussfolgerung ist für uns:
Wir können mit Fluid so nicht arbeiten und müssen nach brauchbaren Lösungen suchen.
Die Frage dazu ist jetzt, wie wir weiter verfahren.
Arbeitet Fluid aus irgendeinem Grund vielleicht fundamental langsamer, wenn man im Development-Kontext ist?
Wir würden - aus oben genannten Gründen - eigentlich gern bei Fluid bleiben und wären grundsätzlich auch bereit, bei Erweiterungen und Verbesserungen zu helfen, soweit wir können.
Nur brauchen wir einen Ansatz - weiß denn wirklich niemand Rat?
Viele Grüße,
Christian
Hallo Christian,
auch ich habe erhebliche Probleme mit dem Fluid-Rendering ( gehabt ).
Lösungsansätze gibt es aktuell zwei.
1. Reduzierung der Partials - wie Du es auch schon gemacht hast.
2. "Splitten" des Renderings in mehrere Requests.
Bei 2. wurde nichts anderes gemacht, als eine gesamte Seite in verschiedene Abschnitte aufzuteilen, die via ajax nachgeladen werden. Meine Erkenntnis war, dass viele verschachtelte Partials schlimmer für die Performance sind, als allein deren Menge.
Die Gesamtladezeit ( kumuliert ) ist mit Ajax vielleicht genau so groß, allerdings werden die nachgeladenen Elemente sehr schnell mit Fluid gerendert. Stellenweise merkt man nicht mal das etwas nachgeladen wird.
Zudem macht man die Ladezeit für den Benutzer erträglicher, wenn er bereits eine Seite sieht und Teile dessen sichtbar ( loading indicator ) nachgeladen werden.
Zum Development-Kontext: Ja, Fluid ( Flow ) arbeitet signifikant langsamer als im Produktiv-Kontext. Die Performance solltest Du nicht im Development-Umfeld messen.
Gruß
Fred