[TYPO3-dev] Performance optimization Typo3

[Ernesto Baschny [cron IT]]

Chris Zepernick {SwiftLizard} schrieb am 16.08.2010 22:42:

> as mentioned in another thread I was working on speeding up
> TYPO3 for the last two weeks, this is why we (freelance team at german
> Telekom) have rebuild the whole sessionhandling of T3 from DB to
> memcache, or better said to use the caching framework.
> 
> Background: We currently have 50.000 FE users and 55 FE groups,
> and we will get additional 80.000 FE users and 100 FE groups by the end
> of this month.
> 
> During that task we discovered serveral little inconvenience
> related to some TYPO3 Core classes.
> 
> First of all we discovered that there is no possibility to check
> whether the Memcache is connected or not, although this information
> is stored within the memcache class in a protected attribute.
> 
> This was solved by implementing a method to get the value of this
> attribute.

Sounds easy. Might be something to include in the core in 4.5? Send the
patch to the core list (using the RFC procedure [1]), if you can.

> Using the caching framework to store the session and session data
> brought up a new problem,.. each time someone cleared the cache all
> FE and BE users are logged out.
> 
> This we solved by impemtenting a method in cachemanger to remove
> a cache config from the list of caches to clear.
> 
> works like charme ;-)

That is very ugly and an issue also for TYPO3 v4.3 and v4.4. Report that
as a bug in the bug tracker. There must be some core place to configure
which caches should be cleared on "clear all" caches. If you have
already implemented the change, just attach your patch that does it to
the bug report (and if you think it is already clean enough, as an RFC
to the core list).

> Last inconvinience we discovered was that the whole user auth process is
> spread accross 4 classes, if you take the switch user function in
> BE into count we have 6 places to change.

It is a hierarchy of classes:

t3lib_userAuth
 extended by t3lib_userAuthGroup
   extended by t3lib_beUserAuth
     extended by t3lib_tsfeBeUserAuth
 extended by tslib_feUserAuth

Each has its purpose. Conceptually it might be done differently
nowadays, but I don't see the inconvenience yet that you encountered.
Maybe if you would share specific problems you had with the current
implementation will open our eyes.

> So, I've got two questions:
> 
> 1. Is the core team interested into the code we implemented (Extension)
>    to perhaps integrate those changes into the core ?

Sure! See above for some methods to accomplish this.

> 2. Whats your opinion, wouldn`t it be nice to have the auth process
>    for BE & FE, including the switch, stored in one place and not
>    4 to 6 ? So we can get a central API for auth ?

I don't think that having one huge "class" doing it all solves the
problem. The "central API" for authentication is service-based, so
different extensions can hook into authentication by just providing a
service. This API has been used for years now to integrate other
authentication methods (LDAP, OpenID, etc) and works very well.

If I understand you well, your problem was that several changes to core
needs to be done to get it scalable. If this is the issue, I would
welcome your patches to the core to improve that situation.

Improving the API would be a next step which is much more difficult
because it has to be backwards compatible. But it also doable!

Cheers,
Ernesto

[1] http://typo3.org/teams/core/core-mailinglist-rules/