TYPO3 6.2 性能，Typoscript Select，Typoscript Cache [英] TYPO3 6.2 performance, Typoscript Select, Typoscript Cache
问题描述
问题本身已经解决，但问题仍然悬而未决，因为我想测试 Krystian 的提示.请参阅此问题底部的编辑 3.
我有一个非常慢的 TYPO3 项目.所以我做了一些测试，发现了一些问题.
I have a TYPO3 project that is very slow. So I did some tests and found some problems.
我测试了起始页，起始页容器 2 个新闻列表(共 9 篇文章)(tx_news 2.3.0 版 - 不是最新的).它包含菜单(用流体 v:page.menu 创建)、页脚(也用 v:page.menu 创建)、右栏(主要是图像内容元素，从另一个带有排版的页面收集)和一个新闻标签列表(用打字稿创建).news-taglist 使用了两次 - 一次在菜单中，一次在右列中.
I tested the startpage, the startpage containers 2 news list (total 9 articles) (tx_news version 2.3.0 - not the newest one). It contains the menu (created with fluid v:page.menu), the footer (also created with v:page.menu), a right column (mainly image content elements, gathered from another page with typoscript) and a news-taglist (created with typoscript). The news-taglist is used twice - once in the menu and once in the right column.
首先是性能概览:
No Menu/No Footer (without taglist), No News, No Labellist
0.65s
With menu and footer (without taglist)
0.95s
With menu and footer (with taglist)
2.3s
With menu and footer (with taglist) and Taglist in right column
3s
With all
4.2s
重点是标签列表(现在总共有 1303 个标签).这是生成标签列表的 Typoscript:
A big point is the taglist (right now there is a total of 1303 tags). here is the Typoscript that generate the taglist:
plugin.tx_mytemplate {
newsTags = CONTENT
newsTags {
table = tx_news_domain_model_tag
select {
pidInList = 1,589
hidden = 0
deleted = 0
orderBy = title
}
orderBy = title
renderObj = COA
renderObj {
1 = LOAD_REGISTER
1 {
Counter.cObject = TEXT
Counter.cObject.data = register:Counter
Counter.cObject.wrap = |+1
Counter.prioriCalc = intval
}
2 = TEXT
2.insertData = 1
2 = TEXT
2.insertData = 1
2.field = title
2.typolink {
# link to page
parameter = 588
# the current tag
additionalParams = &tx_news_pi1[overwriteDemand][tags]={field:uid}
additionalParams.insertData = 1
}
2.wrap = <li data-test="{field:uid}" data-index="{register:Counter}">|</li>
}
wrap = <ul>|</ul>
}
}
我在菜单中使用了一次，在内容元素中使用了一次:
I use this once in the menu and once in a content element with:
<f:cObject typoscriptObjectPath="plugin.tx_mytemplate.newsTags" />
我不明白的是，根据我的理解，使用一次或两次(甚至更多)应该没有太大区别，因为在第一次使用之后应该创建typoscript-object并且没有必要第二次创建它.我在这里遗漏了什么吗?
What I don't understand is, for my understanding there should not be a big difference in using it once or twice (or even more), cause after the first use the typoscript-object should be created and there is no need to create it a second time. Am I missing something here?
这是 SQL:
SELECT * FROM tx_news_domain_model_tag WHERE tx_news_domain_model_tag.pid IN (1,589) AND tx_news_domain_model_tag.deleted=0 AND tx_news_domain_model_tag.hidden=0 ORDER BY title;
执行此查询需要 0.004 秒.所以我不明白的另一点是，为什么创建这个打字稿对象如此昂贵?是用于创建所有 1303 个链接的拼写链接吗?(我用的是realURL)
It needs 0.004s to execute this query. So the other point I don't understand is, why is it so expensive to create this typoscript-object? Is it the typolink that is used to create all 1303 Links? (I used realURL)
此外，这个标签列表不会经常更改，是否可以以某种方式完全缓存它?例如，仅在执行 Flush 通用缓存(或前端缓存)时才创建新的标记列表?
Also, this taglist does not change often, is it somehow possible to full cache it? And for example only create a new taglist when Flush general caches (or frontend cahches) is executed?
还有其他想法吗?(我知道我可以在页面加载后通过 ajax 加载标签列表，但这只是最后的工作，也许有更好的解决方案)
Any other ideas? ( I know I could load the taglist via ajax after the page is loaded, but that is just the last work around and maybe there are better solutions)
我测试了没有打字链接的标签列表，速度快了大约 1 秒.这意味着为 1303 Link 创建一个错字链接大约需要 1 秒.
I tested the taglist without the typolink and its around 1s faster. That means to create a typolink for 1303 Link costs around 1s.
编辑 2: 我发现了一个隐藏的 config.no_cache = 1 并且现在测试是否在启用缓存时一切正常.但无论如何，我很感兴趣为什么 Typlink 如此昂贵.
Edit 2: I found a hidden config.no_cache = 1 And testing right now if everything works when cache is enabled. But anyway I am interessted why typolink is so expensive.
.
plugin.tx_mytemplate {
newsTags = CONTENT
newsTags {
table = tx_news_domain_model_tag
select {
pidInList = 1,589
hidden = 0
deleted = 0
orderBy = title
}
orderBy = title
renderObj = COA
renderObj {
1 = LOAD_REGISTER
1 {
Counter.cObject = TEXT
Counter.cObject.data = register:Counter
Counter.cObject.wrap = |+1
Counter.prioriCalc = intval
}
2 = TEXT
2.insertData = 1
2 = TEXT
2.insertData = 1
2.field = title
2.typolink {
# link to page
parameter = 588
# the current tag
additionalParams = &tx_news_pi1[overwriteDemand][tags]={field:uid}
additionalParams.insertData = 1
}
2.wrap = <li data-test="{field:uid}" data-index="{register:Counter}">|</li>
}
wrap = <ul>|</ul>
stdWrap.cache.key = mytaglist
stdWrap.cache.lifetime = unlimited
}
}
我看不到加载时间有任何变化.有没有办法检查这个对象是否真的被缓存了?我做错了什么吗?
I can't see any changes in loading time. is there a way to check if this object really gets cached? Did I something wrong?
我换了
<f:cObject typoscriptObjectPath="plugin.tx_mytemplate.newsTags" />
与
<v:render.cache content="<f:cObject typoscriptObjectPath='plugin.tx_mytemplate.newsTags' />" identity="test1234" />
它似乎有效，因为第一次调用需要更长的时间.但是接下来的调用是正常的"(因为我不会使用 v.render.cache)，直到我取出内容部分并只使用标识:
It seems to work, cause the first call needs longer. But then the next call is "normal" (as I would not use the v.render.cache) until I take the content part out and just use the identify:
<v:render.cache content="test" identity="test1234" />
这更快并且仍然显示标签列表.到目前为止，它的工作原理是使用 test1234 后面的缓存版本.但似乎他每次都在内容部分渲染f:cObject Typscript object.我在这里错过了什么?
This is faster and still displays the taglist. So it works so far, that the cached version behind test1234 is used. But it also seems that he render the f:cObject typoscript object in the content part every time. What am I missing here?
更奇怪的是，当我使用带有 content="test" 和 flush frontend caches 和 flush general caches 的代码时，标签列表是仍然显示(而不是测试").文档说:这个ViewHelper背后的缓存是Extbase对象缓存，当你清除页面内容缓存时会被清除..页面内容缓存究竟是什么?不是两个 flush frontend caches 或 flush general caches 之一吗?
Even stranger is, when I use the code with content="test"and flush frontend caches and flush general caches the taglist is still displayed (and not "test"). The docu says: The cache behind this ViewHelper is the Extbase object cache, which is cleared when you clear the page content cache.. What exactly is the page content cache? Not one of the two flush frontend caches or flush general caches ?
编辑 4: 启用缓存后，我发现新闻插件存在问题.我使用 realURL 作为新闻插件:
Edit 4: With cache enabled I found a problem with the news plugin. I use realURL for the newsplugin:
'category' => array(
array(
'GETvar' => 'tx_news_pi1[overwriteDemand][categories]',
'lookUpTable' => array(
'table' => 'tx_news_domain_model_category',
'id_field' => 'uid',
'alias_field' => 'CONCAT(title, "-", uid)',
'addWhereClause' => ' AND NOT deleted',
'useUniqueCache' => 1,
'useUniqueCache_conf' => array(
'strtolower' => 1,
'spaceCharacter' => '-'
)
)
)
),
'tag' => array(
array(
'GETvar' => 'tx_news_pi1[overwriteDemand][tags]',
'lookUpTable' => array(
'table' => 'tx_news_domain_model_tag',
'id_field' => 'uid',
'alias_field' => 'CONCAT(title, "-", uid)',
'addWhereClause' => ' AND NOT deleted',
'useUniqueCache' => 1,
'useUniqueCache_conf' => array(
'strtolower' => 1,
'spaceCharacter' => '-'
)
)
)
),
调用类别链接没有问题，但是当我调用标签链接时，我只能看到第一次点击的新闻(更改标签不会影响任何事情，它仍然显示由第一个标签过滤的新闻).所以缓存似乎出了点问题，但我不知道是什么.对我来说，类别和标签看起来几乎一样，唯一的区别是另一个参数，但 realURL 应该处理.
Calling a category link works without problem, but when I call a tag link then I see only the news from the first hit (changing the tag does not affect anything, it still shows the news filtered by the first tag). So it seems something went wrong there with the cache, but I can not figure out what. For me categories and tag looks pretty much the same, the only difference is another parameter, but realURL should handle that.
推荐答案
试试看:
plugin.tx_mytemplate = TEXT
plugin.tx_mytemplate {
stdWrap.cache.key = mytaglist
stdWrap.cache.lifetime = unlimited
stdWrap.append = CONTENT
stdWrap.append {
# ... your TS
}
}
这篇关于TYPO3 6.2 性能，Typoscript Select，Typoscript Cache的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
