[TYPO3-dev] Performance optimization Typo3

[Chris Zepernick {SwiftLizard}]

Hey,

>
> Yes, you already mentioned that in another thread. I have this issue on
> my radar, but didn't had the time to take a look. It would be great if
> you could open a bugtracker issue with your patch for detailed analysis.
>
I on my way,... we realized this as an extension so we wouldn´t have to
patch the core too much,.. so I will download current typo3 release
and integrate the patches there in order to provide patch file.

I think I will manage to finish that one until Friday.

>
>> 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.
>
> - It's a cache, and as such volatile. Same will happen if your memcache
> servers fail, if the cache gets corrupted, on network fail ...

true, thats why we only store the session data in there, to reduce the 
load at the server.

>There are
> articles on the net which recommend to just use a cache in front of a
> persistent database for this reason if handling sessions (I'll search
> for links if you are interested), so write operations should go to
> memcache and db, and read operations to cache first.

Nope this caused the inital problem, and is the reason why we, and 
another agency seperated that from the mysql db in the first place.

We went for memcache, they went for couch db.

At the moment session and session_data is read several times at page 
load by typo3 itself, at the same time there are several inserts and 
deletes. This comes per page load per user.

If you run systems in a normal typo3 scope this might be no problem, but 
if you have a high traffic installation with several hundert thousand 
users that have several different usergroups assigned this is a major 
problem.

> - Did you benchmark your memcache setup against an optimized mysql? In
> the end we are just talking about 100k FE users, mysql can easily handle
> this. Where is the real bottleneck with the db setup? Is it the comma
> separated group assignment in TYPO3?

The bottleneck is not the DB itself, the bottleneck is the way typo3 
works in this case. As mentioned above typo3 reads and writes several 
times at page load form and to db only to get and update the session.

Some of this is due the fact that we are not able to use mysql sepecific
features, because other dbs don´t have them. (INSERT ... ON DUBLIKATE 
KEY UPDATE ...)

>
>
>> This we solved by impemtenting a method in cachemanger to remove
>> a cache config from the list of caches to clear.
>
> There is a hook in the clear cache drop down to handle additional cache
> clearing. If this can't be used to unregister a cache from clearing, we
> could change / add a hook that fits for this purpose.

Nope this hook only provides us with an option to add new items to that 
menu.

The other problem we have at the moment is that the cache flush options
in the top of TYPO3 BE only work for TYPO3 core caches but not for usage 
of the  caching framework in FE.

Perhaps we should come up  with a solution for that one too, to my mind
as a user i would expect the the cache of all exts is flushed if i use 
that buttons, if those exts are not configured to not react to this command.


Cheers chris

>
>
> Regards
> Christian