[TYPO3-core] Announcing TYPO3 CMS 6.1.0 Alpha1

bernd wilke t3ng at bernd-wilke.net
Fri Mar 15 10:13:29 CET 2013

Am 15.03.2013 08:44, schrieb Peter Niederlag:
> Hello,
> On 14.03.2013 20:12, JoH asenau wrote:
>> Am 14.03.2013 19:04, schrieb Christian Kuhn:
> [...]
>> BTW: I don't know what would be realistic use cases for the number of
>> concurrent requests in the "real world" you had in mind, but in the real
>> world of some TYPO3 projects I know of, these are the average numbers
>> the QA people are working with, since they have to handle up to 400/s
>> during peak times on a 4.5 LTS based instance.
> If you serve 400 requests/s cached pages straight out of TYPO3 without a
> caching proxy in front imho you are NOT enterprise but wasting cpu
> cycles. ;)
> [...]
> Gathering these numbers definitly is a very nice effort, thx for that!
> However I think it really needs some thinking/description of scenarios
> that are common and need to be considered for these comparisons:
> Scenario I:
> - stock cached content page with 2 Text and 2 Text/Image Elements, TV
> and realurl
> Scenario II:
> - stock cached content page with 2 Text and 2 Text/Image Elements, TV
> and realurl plus cached extbase plugin (TCA in Frontend required)
> Scenario III:
> - stock cached content page with 2 Text and 2 Text/Image Elements, TV
> and realurl plus USER_INT extbase plugin (TCA in Frontend required)
> All of these scenarios should also be run with a no_cache=1 setting
> applied, as this also matters.

two anotations:
1. not everybody uses TV which does a complete change in page-rendering
2. pi-based extension are not depricated and there are a lot of them!

therefore I would suggest these scenarios:
one with tt_news, one with tx_news

and maybe some extension which change performance depending on number of 
records. something like a catalog with different categories and the 
display of number of items in each category WITHIN the actual preselection.

> Also the settings chosen should be discussed. While I believe it makes
> very much sense to deliver packages with deprecation-log enabled I
> believe it makes much more sense to disable it when trying to get
> numbers for "how fast does TYPO3 serve in production mode".
> On the other hand, it would even make sense to get some facts for "how
> fast does TYPO3 serve in development mode". Concurrency would be rather
> low here.

maybe three standardised modes like http://pi-phi.de/291.html

> IMHO we are only starting to get into this and it would be very, very
> cool if you could keep this up and we can get more of these numbers
> based on different scenarios on a regular base.


More information about the TYPO3-team-core mailing list