[TYPO3-Performance] General questions

[Mathias Schreiber [TYPO3]]

Martin Kutschker schrieb:
 > Mathias Schreiber [TYPO3] schrieb:
 >> You will see that a lot of queries run multiple times.
 >> E.g. Let's say you hit one page 20 times - this should result in a
 >> queryCount of 20 for query A (at least this would be the ideal 
situation).
 >> But query A is executed over a thousand times.
 >
 > One query is the access rights query in tslib_content for a page. This
 > is done for each CONTENT object. If you have multiple columns, you'll
 > get the same query repeated. But it's excatly the same so, Mysql query
 > cache will help.

Your example is basically ok, since the query won't be the same.
It will be much alike, but not really the same one.
t3lib_page->getRootline ist something that could be improved massively.
Thing is, that the solution is that obvious that I am not sure if it 
breaks some other things.
But up to now everything works out fine.

I still think that caching the query in mysql is basically a good thing, 
but removing duplicate queries (real dupes) will be faster, any way you 
put it.

In order to find things like this fast I think it is helpful to analyse 
which functions are called multiple times, then check WHY they are 
called multiple times ad remove the cause of the duplicate calls.
This way workspaces stuff like Dmitry pointed out could still remain in 
the core (although at least for me it is a total waste of resources), 
because we speed things up at another point.

Another way might be to check which "extensions" are used by the core.
Nothing against workspaces... but you don't really need them in every 
TYPO3 install, but you loose the speed in every install.

 > Another odd thing is that at least for BE authentication the
 > authentication tables are queried twice. Some strange logic checks and
 > then rechecks them.

I could try to did up our VM that hosted the MSSQL DBAL implementation.
The query analyzer in MSSQL ist the best I've seen so far (I'm sure the 
oracle thingy catched up, but never saw the new one though).

If we stick to the "everyone can use" approach I could xclass DBAL for 
logging all queries like we did in our tests and wrap everything up with 
a nice reporting module (ok, forget about "nice" ;-)) so everyone can 
see for himself.

I am so damn sure that our two monitored installs are only the tip of 
the iceberg, so the more people log, the clearer we will see what stuff 
is called too often.

And once we have this data, we can start working on the issues.
Since we let most of the analysis be done by computers, we drastically 
reduce our own analysis workload (Idea: let the machine work).

But since logging each query is a massive mysql ovrhead I recommend to 
use this only when you are REALLY sure, what you're doing - of course 
production machines would be perfect, because they will always return 
much more detailed results than lab-environments.


Volunteers? :)

-- 
T3A AM
Rocking TYPO3 since 3.1b1