[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