[TYPO3-english] TYPO3 6.x caches and performance best practices for productive site

Steffen Gebert steffen.gebert at typo3.org
Fri Mar 1 08:17:50 CET 2013

Hash: SHA1

Hi Domi,

> The most I could read out with my little
> knowledge is, that there are tons of DB queries which get handled on
> each page uncached. But it was hard to read, which one is the main
> trouble maker...

What's "tons" in numbers? 2000?
- From where do these queries originate and what tables are they reading?
(first one comes from the profiler, second information from your mysql log).

Would you mind uploading the cachegrind file somewhere (btw. the XHProf
file would be like 1000 times smaller ;-))

typolink is a very bad function in terms of SQL queries, but there are
two improvements:

In 6.0, the rootline cache is back.

For 6.1, I contributed a sys_domain (runtime) cache, which prevents
couple of queries in case of config.typolinkEnableLinksAcrossDomains
Once RealURL is using that, another big amount of redundant queries can
be saved.
You might want to backport this, if you have lots of queries to

Kind regards

- -- 
Steffen Gebert
TYPO3 Server Administration Team Member

TYPO3 .... inspiring people to share!
Get involved: http://typo3.org

I work for TYPO3 solely in my spare time. If you think that
my work helps you running your business, you are invited to
send me a donation via PayPal to this email address. Thanks

On 2/28/13 11:37 AM, Domi wrote:
> Hello Andreas and Christian,
>> - Make sure t3lib_cs_convMethod and t3lib_cs_utils use mbstring or iconv
>> (see install tool).
> Thanks I never was checking on this two options. Will set it to mbstring
> because this post says it should be faster:
> http://web.archive.org/web/20090221171406/http://dokeoslead.wordpress.com/2008/10/05/mbstring-vs-iconv-benchmarking/
>> - If you're using extbase with bigger domain models, make sure to use
>> lazy loading where possible. If done right, its fully transparent. If
>> not done, it can easily lead to thousands of db requests. A good
>> indicator is to enable mysql logging (on your development system) and
>> see which db calls are fired.
> Thanks for the hint. My extbase extensions weren't fired on the pages
> where I did my testings. But for sure I need to keep an eye on it.
>> - Try to configure some caches to reduce number of db queries. For
>> example the extbase 'object' cache can get quite a number of db calls
>> per request, but it is not very big in size and uses no tagging. Thus,
>> it is a good candidate to switch it to APC cache if you are using apc
>> and have some little free mb in there.
>> Most important: Throw a profiler like xhprof or cachegrind to one of
>> your calls and find out about your bottleneck.
> I am using the profiler of xDebug inside of PhpStorm and also a
> visualization with cachegrind. The most I could read out with my little
> knowledge is, that there are tons of DB queries which get handled on
> each page uncached. But it was hard to read, which one is the main
> trouble maker...
>> In general, performance tuning usually means to find the *big* thing
>> first and fix it. Often, the biggest issue (whatever it is) takes maybe
>> 80% of your rendering time, so fixing it will give you a factor of five.
>> All other things are minor until then.
> The biggest things I figured out till now where the DB queries for my
> main menu and all 9 content sections, which getting called via the
> styles.content.get.
> Is there anything you guys do, that all pages getting regularly crawled
> that every page is cached?
> Thanks for all the useful information.
> Dominic
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the TYPO3-english mailing list