[TYPO3-Performance] General questions

Mathias Schreiber [TYPO3] mathias at typo3.org
Mon Aug 4 21:58:37 CEST 2008


Dmitry Dulepov [typo3] schrieb:

Hola

> Mathias Schreiber [TYPO3] wrote:
>> I'll try it with numbers then:
>> Does compressing 10.000 mysql queries make TYPO3 faster than just 
>> sending 120 queries?
>>
>> You see, the problem is that TYPO3 does too may queries which are not 
>> needed.
> 
> Ok. Do you want to go and get rid of those queries in any close time? I 
> doubt so. This will require at least a month of full time work. So I 
> proposed you the immediate working solution for the current TYPO3 version.

I know and I basically was thankful... but I try to get to the base of 
the problem.

Luckily we already did (almost) a month of full time work and dug deep 
into the "too many queries" problem.

That's why I wanted to start there.

What you can do is set up a site with a lot of content and a rather big 
pagetree.

Then xclass t3lib_db so every query gets stored in a seperate database 
table.

After you surf around the site for some time do something like this:
SELECT COUNT(*) as brace_yourself,query FROM your_log_table GROUP BY query.

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.
So something does go wrong (please correct me, if i'm wrong).

>> So my point is to work on stuff we KNOW, not what we "think it might be".
> 
> I do not just think. I know. That's the point.

Me neither - but I think our approaches are different.

>> And then static file caching.
> 
> Well, I did not ask you to use static file caching. I asked you to 
> enabling caching pages to files. See the difference?

My bad, please accept this apology.

>> I think it is dangerous to claim that uncached content isn't a problem 
>> if it takes ages to render, because everything is good once it is cached.
> 
> No one claimed it.

You didn't, on the snowboard tour I heard different stuff about this 
issue (which gives me BAAAAAAAAD headaches) :)

>> My intention is to get rid of stuff that is happening before a page is 
>> being cached.
> 
> Not possible without disabling lots of TYPO3 functionality. Optimization 
> is possible. Getting rid of that "stuff" is not.

See my example above, maybe this clears things up a bit where I want to go.

>> P.S. If you all want to have some fun, set up a website with TYPO3 3.5.
>> I did for fun and it does exactely the same thing as 4.2.0 but is 
>> three times faster :)
> 
> You know why? ;) For example, get rid of some workspace queries in the 
> core and you will see a performance increase.

Yes please :)
We get along without workspaces very well.
But I know that unfourtunately making the use of WS inside TYPO3 
configurable sounds like a pretty tough task.
A nice thing would be some sort of "I don't use WS - skip this part of 
the processing" switch.

>> P.P.S. less personal attacks would be highly appreciated
> 
> I simply a bit frustrated. I give you solutions because I know that they 
> are tested and work. You doubt it and reply with theories that are not 
> proved by anything. I tell you to use file-based caching and you confuse 
> it with static files... How should it look from here? Sorry if my 
> previous mail looked rude. But you had a problem with performance, I 
> tried to help. Asking for help and refusing to accept it does not look 
> right.

Classic misunderstanding.
My approach goes much deeper than tuning performance in a certain situation.

I analysed (and still do) what TYPO3 does in order to render a page and 
try to optimize there.

I took a quick look at your (I thought it was you, the text from the 
install tool somewhat sounds like "Dmitry" ;-)) pageToHarddisk switch in 
the install tool, which looks interesting, but have to admit that I 
don't know why it doesn't go the whole 9 yards and also deletes the 
files when needed.

It's late so I will come up with a processing hook for that anytime soon.

But you will also understand that I am frustrated when I see great 
concepts not being done properly.

Like the rootline caching.
Cache = good
Nuking cache each loop = ...I can't think of a nice way to describe this 
- it's... I don't know, but you get the point.

Anyways:
a good thing would be if we ALL would put together all our experiences 
in one place.
Then define a way how patches are being applied to the core branch.

I fear that (as so often) we work hard and the desperately needed 
patches are lost in someones mailbox (happened to me 4 times, so attempt 
5 has to work, otherwise I gotta do my own thing).

So I'd like to have one "official" coredev in charge of the results of 
all this discussion.

Does make sense to me, what do you think?

best
Mathias

-- 
T3A AM
Rocking TYPO3 since 3.1b1


More information about the TYPO3-Performance mailing list