[TYPO3-Performance] General questions

[georg kuehnberger]

Mathias Schreiber [TYPO3] wrote:
> 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.

ACK, Same over here; mysql always (in our installations) needs less CPU 
then apache/php; the more personalization the higher the load, however 
always lower than apache;


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

I would not loose time with too much daemon config-details, as they 
might massively differ per installation / availabile hardware.
Meaning: write up a guide on basic meaninful settings and refer to the 
tuning-guides of the manufacturerer. hint: this part is NOT TYPO3 specific.
Better invest the effort in avoiding the TYPO3-core performance issues.


>>> 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 ;-)

NO, we wont start that discussion here as it's not TYPO3 specific.

>>> 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.
ACK
in addition to code-wise fixes in the CORE, we should also include 
config-related recommendations;

regards georg