[TYPO3-core] RFC: #8515: Speed up tslib_cObj->getTreeList by caching its results

Dmitry Dulepov [typo3] dmitry at typo3.org
Tue Jul 15 15:10:47 CEST 2008


Hi!

Michael Stucki wrote:
> So how about using cache_hash then? I just thought about the same today, so
> good to see it in your post, too.

<offtopic>I plan an article about related question in my blog. It should be out tomorrow or on Thursday ;)</offtopic>

Generally having hundreds thousands of rows in one mysql table is risky. Especially if primary key is semi-random data like md5 hash. It cannot be organized well into index. Eventually MySQL will be forced to go for full table scans. Result will be the same as in old indexed search: several seconds on several concurrent queries.

I would say once we will need to rethink our cache system. Kasper tried to make file-based cache but in practice it does not speed up the whole thing much. I measured it on a live site in 30 min intervals withing several hours - no much effect. The large the site, the slower cache. Add also 500 groups to a web site with 10000 pages and problems will become more noticeable.

> cache_hash uses a combined key of hash and type identifier which can be any
> action like those for example:
> - PAGES_TSconfig
> - TMPL CONDITIONS - ALL
> - MENUDATA
> - FE_TREELIST (proposal for new key)
> 
> etc.
> 
> The reason behind that is that I think we will need a similar cache for
> t3lib_pageSelect::getRootLine() and similar functions soon.
> 
> A possible compromise for Dmitrys doubts could be implemented by a
> configuration setting of hash types which are never cached, e.g.
> $TYPO3_CONF_VARS[SYS][skipHashTypes] = MENUDATA,FE_TREELIST

This is a good idea! I really like it!

-- 
Dmitry Dulepov
TYPO3 Core team
More about TYPO3: http://typo3bloke.net/
Subscribe: http://typo3bloke.net/rss.xml


More information about the TYPO3-team-core mailing list