fluid tempalates are not cached in fluidcontent

[kszymukowicz]

hi

Facts:

1) Flux 6.0.1 / fluid content 3.1.0

2) There is ArticleTeaser.html which has 290 lines. The rendering time of that CE is 800ms. Becase this is ArticleTeaser sometimes I have 10 CE like this on one page. It takes 10 * 800ms = 8 sec (!) to render that page.

3) I was suspecting that maybe this is becase some DB long query but from my investigation none of the fluid/flux part has significant influence on this 800ms. Each removed part of fluid/flux lower the time of rendering by some ms. Almost linear.

This are the data:

1. No changes - rendering time: aprox 800ms
2. Remove whole flux defs - rendering time: aprox 700ms
3. Remove Main section content - rendering time: approx 500ms
4. Remove Section Readmore - rendering time:approx 450mx
5. Remove Section ReadmoreImage - rendering time:approx 435ms
6. Remove Section Readmore1 - rendering time:approx 300ms
7. Remove Section Readmore2 - rendering time: approx 187ms
8. Remove Section Readmore3 - rendering time: approx 50ms

As you see after removing content of Main section the parsing time is still high altough nothing sould be calculated becase "Main" is empty, right ?

For me it quite obvuios that the fluid tempalte is not cached and its parsed each time even if nothing is done in that file.

[kszymukowicz]

Claus suggested that this is becase some of the VH can turn "no cache" on template and suggested <v:switch I removed that VH from tempalte. Now there are only standarf <f: VH but still tempalte is not cached.

Any suggestion?

[danilobuerger]

@t33k are you talking BE or FE ?

[kszymukowicz]

FE

Look at this gist

1) https://gist.github.com/anonymous/abce1d50f7641fa18c71 It has about 20 f:if and renders 200ms

2) https://gist.github.com/anonymous/beb2b93d98df97bdecdb It has only 1 f:if and renders 60ms

140ms / 20 = about 7ms per one f:if ? This is crazy if this is the speed of compiled fluid.

[danilobuerger]

And the render time you mentioned (200ms / 60 ms) is when the template is already supposed to be cached? Which Typo3 version are you using?

[kszymukowicz]

TYPo3 6.1.3

TEST 1) browser is A not logged to BE 2) from browser B I clear all the cache 3) on browser A I open page X (for warm cache) 4) on browser A I open page Y with no CE at all = 1,5s 5) on browser A I open page Z with 5 Ce each 100 "f:if" in fluid tempalte 5 second 6) on browser A I open page Z1 with 5 Ce each 100 "f:if" in fluid tempalte - again 5 second 7) on browser A I open page Z with 5 Ce each 100 "f:if" in fluid - second hit - 0,5sek - its taken from TYPO3 cache 8) on browser A I open page Z1 with 5 Ce each 100 "f:if" in fluid - second hit - 0,5sek - its taken from TYPO3 cache

[kszymukowicz]

Can anyone reproduce that or its only on my TYPO3 installation ?

[NamelessCoder]

Hi @t33k - are you using realurl? And does the problem continue if you create a new page with the exact same content (not copy, new from scratch)? If the answer to both of those are "yes" then I have some bad news about realurl's internal cache - there's a bad bug in there somewhere which causes cHash calculations to go wrong or be missing, which makes TYPO3 6.1 at least, render all content as _INT but the page itself as cached (yeah, odd symptom, I know).

I have encountered this in one case only - and it had pretty much the exact symptoms you mention. It was solved by manually clearing every file and DB entry generated by realurl...

Cheers, Claus

[kszymukowicz]

Sry for late answer.

Yes - I use real url but even after disabling realurl the behavior was the same.

What I did: 1) I simplified the template a lot This gave me about 300ms save on each teaser - so now each one was generating 500ms - still lot.

2) I added indexes to 6.1.7 FAL tables. I read whats new in FAL 6.2 that they improved FAL speed by adding indexes. In this specific install there is quite lot of files. sys_file 6.500 sys_file_processedfile - 12.000 So I suspected - it could help. Guess what? It gaves me another 200ms of saving.

Now each teaser is rendering about 320ms (from 800-900ms at beginning). That's the acceptable level.

Interesting is that after cleaning lot of "f:if" the template cache for this ArticleTeaser in typo3temp/Cache/Code/fluid_template/ went down from 800kB to 132kB!

[NamelessCoder]

Hi @t33k - thanks for getting back to us. Looks like we've eliminated possible cHash issues as cause and identified part FAL, part template complexity as cause. Especially thanks for that last note about cache size - I knew that f:if does generate "hardcoded" conditions in the cached code but that ratio looks pretty damn scary...

[cedricziel]

AFAIK the template cache is part of the problem for not only caching the critical path, but also one that reflects the cyclomatic complexity. - So, while fluid templating is still relatively young, there is a chance that being able to cache the templates in a faster way could improve this. - But that's barely FT3 related-we only stand in line with all the others -.-

Let's hope the AC team will identify some bottlenecks there as well.

Thank you Krystian!

[twirsing]

Cedric Ziel schrieb:

AFAIK the template cache is part of the problem for not only caching the critical path, but also one that reflects the cyclomatic complexity. - So, while fluid templating is still relatively young, there is a chance that being able to cache the templates in a faster way could improve this. - But that's barely FT3 related-we only stand in line with all the others -.-

Let's hope the AC team will identify some bottlenecks there as well.

Thank you Krystian!

— Reply to this email directly or view it on GitHub https://github.com/FluidTYPO3/flux/issues/392#issuecomment-33116065.