[TYPO3-Performance] General questions

[Mathias Schreiber [TYPO3]]

georg kuehnberger schrieb:
>> 1) Bottleneck
>>    What do you think is the bottleneck in your installations?
>>    1.a) Apache Webserver + PHP
>>    1.b) MySQL Server
> neigther; but rather the useless ping-pong between php and mysql;

That's interesting.
We seperated DB and Apache/PHP and while PHP still loads up the server, 
mySQL keeps idleing around at 5% CPU and RAM load.

So I think we will have to take a deeper look at how the servers are 
configured.

>> 2) Tuning needed
>>    2.a) Generating the pages
>>    2.b) Fetching pages from DB cache
> a !
> 
>> 3) Does your website use Logins?
>>    3.a) no
>>    3.b) yes, a little (stuff <10% of the pags goes here)
>>    3.c) yes, quite a lot
>>    3.d) our website requires a login for most of its content
> 
> This differs per project; the ones with more personalization suffer 
> badly (performance-wise). Workaround for the really personalized stuff 
> for me seems to use eID being loaded via ajax, which allows the rest 
> nonpersonalized stuff to be cached by TYPO3;

We did that in some projects (for shopping baskets also btw.) and it 
works quite good - parseTimes go down from 2500ms to 200ms at MUCH less 
load.
But now the whole "Javascript is bad" discussion might pop up which I'd 
like to avoid ;-)

>> 4) Do you NEED USER_INT objects on your pages?
>>    4.a) yes
>>    4.b) yes, but I could handle this via AJAX and eID
>>    4.c) no, but I have them because I was lazy at some point
>>    4.d) no
>>    4.e) USER_WHAT?
> 
> d) + c)

THanks for being honest with c :)

>> 5) Workflow in general
>> If I find a flaw, what do I do?
>> Do I write a patch?
>> If so, when will it be checked?
>> If checked, when will it be applied?
>>
>> THis list could of course be continued like forever but I gues if you 
>> read the first few things you get the point...
> 
> In general I would vote for
> a) focus on reducing the number of DB-calls, both in the core and also 
> in the various "important" extensions.

agreed... core first IMO.

> b) working on more clever cache-concepts (like real object caching, 
> cache-headers and more)
> 
> I get the point that the mentioned PHP-tricks (which function is faster 
> than the other) are valid, however I dont feel like this would do any 
> meaningful impact on performance compared to the other bottlenecks.

... which should not mean to abandon them altogether, but to fix the 
obvious stuff first.

> Recently I saw a T3-Site, which (on descent hardare) takes up to 10+ 
> seconds to generate a non-cached FE-Page, simple for the reason of 
> having 30+ Content-Elements / Plugins on the page, which results in 
> endless ping-pong;

tell me... :(

> From experience I know, that it's best to fix the slowest 20% and you 
> will gain 80% performance-improovement.

+

> As for the DBAL discussion & your question: yes we did one postgresql 
> setup, however this was for demonstratingt the client that mysql is 
> faster only (was ~ factor 8); so no we dont use it in production.
> And meanwhile, as mysql has gained much more respect on the market 
> (inkl. being bought by SUN), we're able to convince even Oracle-Clients 
> to buy into mysql.

...hehe...thought so...

thanks a lot,

I will contact Oliver Hader and see what we can do

-- 
T3A AM
Rocking TYPO3 since 3.1b1