[TYPO3-Performance] db-performance-issue

Mathias Schreiber [TYPO3] mathias at typo3.org
Wed Jul 30 14:54:09 CEST 2008


Michiel Roos [netcreators] schrieb:
> But freedom of choice is nice. And since TYPO3 advertises the dbal as
> one of the great features . . .
> 
> I think we should stick with it.

I have to admit that I'd rather trade losing the DBAL if I gain a 
significant increase in rendering speed.

Freedom of choice.... hmm... I get your point, but if I am right we have 
like 20 DBAL installs compared to what... 20.000 MySQL Installs...
I go for "to heck with freedom" ;-)

> I have yet to see a database intensive TYPO3 application besides
> indexed_search.

Set up a sitemap that has 300 pages displayed, enable realURL, get 
18.000 (no kidding) database queries.

> Most output can be cached by TYPO3 if extensions are properly written.

except for content that cannot be cached... see below.

> So the point Andy makes about 'being more performant in fact of faster
> results and less server-stress' becomes moot then.

Less load would make sense under ANY circumstances.

> Well, apart from the 'first hit' of course.

This is the important point.
If you have pages that are fe_user protected static file caching becomes 
impossible (or i have not yet come up with a concept how to do this), so 
the cache has to be delivered from the DB.

Since "first hit" is something rather undefined things get tricky.
Let's say I got a website which comes with 600 pages in 5 languages.
This makes 3000 cached pages.
Now add a tt_news repository with 11.000 news records.

Now comes the best part.
We found that pages are being cached with the current usergroup logged 
on in mind.
So if I have 2 usergroups my content get's cached quite often...
We found the same page being cached for the usergroup combination "4,11" 
and for "11,4".

So the odds of hitting a page that actually could have been cached are 
quite small.

So precaching comes into play.
But in order to create the cache in time (means fast enough) general 
performance needs to be increased.

And before people start shouting "my for() loop is faster than..." it 
would make sense to see, why TYPO3 sets up thousands of queries to MySQL.

While we did our MSSQL DBAL implementation we had a query profiler 
running...
I don't get why the currently logged on fe_user_session
- is being fetched
- then checked against the DB
- deleted
- inserted
- fetched again
- checked again
- deleted
- inserted
- fetched AGAIN (no kidding)
- checked (I'm serious)
- deleted (you see where this is going? :))
- and then inserted.



-- 
T3A AM
Rocking TYPO3 since 3.1b1


More information about the TYPO3-Performance mailing list