[TYPO3-core] Kickoff: TYPO3 4.1 (suggestions)

[Dmitry Dulepov]

Hi!

(While rereading this message I found it a bit chaotic but we are 
brainstorming, so it should be ok)

Kasper Skårhøj wrote:
>> http://www.lartob.de/x-desktop.org/releases/r1/index.html
>> This is a full demo, so takes long time to load. This is like a virtual
>> desktop. Typo3 BE may consist from applications (BE modules) that run in
>> virtual Windows. Thus admin could edit template, DS and see page preview
>>   in tiled windows.
>>
>> Do I dream too much? But this is the feature. Popup menus were made when
>> screens were small, they are old for today.
> 
> Good approach for 5.0. My suggestion is a nice compromise with a low 
> footprint on change management.

May I volunteer to prototype it a bit? :) I may play with X-desktop, 
check licensing, etc, and see if it fits to our needs.

> Where is the bottleneck in the backend?

For example, list module is slow to open.

There are many inline JavaScripts in alt_doc-based pages. These 
JavaScript repeat all the time and create huge pages (slow to access 
during peak hours). This particular thing can be solved with putting all 
JS to separate files, so that it can be cached.

I think we need a secondary query cache in typo3. If there are repeating 
queries, results can be reused, etc. I have in mind to log all executed 
queries and see if can optimize anything.

Some queries query for * even if they need only several fields.

Most places in BE do not close resultsets, thus not freeing memory and 
affecting performance. When I had to optimize my own app, I found that 
closing resultsets decreases memory usage by Apache and increases 
performance by lowering amount of OS swapping.

There are many things. I think careful review of each BE module is 
needed from performance view.

For example, I have real problems working in BE during evening, while FE 
runs much faster and separate PHP/MySQL app runs even faster (though 
this app gets more hits than FE).

>> Performance is bleeding already I think. We cannot close eyes to it for
>> longer or others may beat us.
> 
> If there are easy things to improve I agree with you (like database 
> indexes to add). Other than that I believe we are slow because we do 
> more - which is our strength. So I think you have to define the playing 
> field before you talk about beating or not. We never tried to win the 
> performance game. I don't see my largest clients having any trouble for 
> instance, they still prefer TYPO3.

I prefer typo3 too, for many reasons :) It is almost perfect for me 
(accepting the fact that there is nothing *absolutely* perfect in the 
world).

I am completely satisfied with typo3 except that I am worrying about 
performance. It is average at the moment and I do not want it to be 
worse. I am trying to look into the future from *average* customer 
perspective. This is what majority is, I believe.

Your largest clients probably have dedicated servers for typo3. This is 
not the case for everyone. Please, understand me: I am not saying that 
typo3 is *bad* in performance, I only say that we need to *improve* it 
before it gets worse due to new features that we may put in.

We must not put "hot" things inside before we carefully evaluate them. 
For example, ajax menu was a good idea but it takes huge time to load at 
peak hours and there is no any sign that it is being loaded (no wait 
cursor, nothing). Editor just continue clicking in hope that it will 
appear and get many menus one under another at the end. Old way was better.

> (BTW, I think TYPO3 5.0 could be significantly slower with objects, but 
> of course it remains to be seen...)

What about having a requirement that every feature, every design 
decision must be evaluted from performance view too? That would be only 
a plus.

-- 
Dmitry Dulepov
http://typo3bloke.net/

"It is our choices, that show what we truly are,
far more than our abilities." (A.P.W.B.D.)