[TYPO3-v4] Core performance for 4.6 and beyond

[Dmitry Dulepov]

Hi!

Just for the record: this e-mail is not attacking or unfriendly. I know it 
can be seen like that but it is not. I only try to express my feelings as a 
user this time (not as a core team member). And yes, I am disappointed...

Christian Kuhn wrote:
> Great, so you now all disadvantages of the memcache backend and why you
> shouldn't use it for serious installations.

LiveJournal uses memcached and serves millions of users with its help! 
Naturally I want to use Memcached too ;) Now you tell me TYPO3 can't work 
with Memcached? Man, everybody can, why TYPO3 can't? :)

> memcache backend sucks with heavy tagging. A backend which scales pretty
> well with tags (we have page and content cache entries with 150 tags and
> more) is native mysql (up to some level) and redis.

Could be but I want memcached! I know how fast it is because I used it and 
many people use it! If Reddit with there traffic uses Memcached [1] and 
highly recommends it, why shouldn't I listen? :) And I am sure many will 
want that too because memcached is very popular and known for high 
performance. Redis is less known. So if we do not fix memcached, we will 
definitely get "slow" and "sucks" marks. You can't tell people "Memcached 
backend sucks" because that actually means "Our implementation sucks" 
because Memcached by itself is fantastic. And if our implementation sucks, 
who cares to use it for big projects? If everybody can make a great 
memcached implementation and we can't, what does that mean in the context 
of our product? Think. In fact, we tell exactly that: "Memcached is great, 
others can use it but we can't, we do not have skills to make it work, we 
suck".

(I know that TYPO3 does not suck, it is all about what other people do. We 
can be proud of our product but others will point finger and say: "they 
can't even work well with memcached!")

> So, your comparison is 'not cached' versus 'tons of caches on different
> levels with cf', and you experience a major loss in performance. It's
> not about 'old caching' versus 'new caching', so your load numbers are
> completely irrelevant for our discussion.

No, you got it wrong :) loadavg=64 with caching framework and 3.5 without 
caching framework (just good old page cache and USER_INT objects, no my own 
cache implementation). So with caching framework on the dedicated server 
with 2 4-core XEONs I got load 64 during normal work.

I tried cached framework the way that any external user will do: use the 
most popular and easy tool - memcached. As a result disabling cache is 
better than cache. Sucks. So my numbers are very relevant. This is real 
world experiment that many will do (and fail)!

> I don't think so. Per cache 2 classes (+2 interfaces and abstracts) are
> needed: FE and BE, they are slim and codewise straight forward. The more
> caches you run the quicker is the instantiation. If you hack up your own
> caching solution for your special need, you might be quicker if done
> right. The high flexibility of the cf is it's main advantage, expecially
> for big projects.

I made only one conclusion: I will not use caching framework. It is not 
worth it. I do not want Redis, I want Memcached. You will tell I am wrong. 
But I have to work with a real huge project and existing tools, which TYPO3 
cannot use properly. Yes, I am unlucky. I have to code that myself again as 
I coded everything from community, forums, chat, etc because there is no 
suitable, optimized extensions available in TER.

Look at the on the wiki: memcached backend is bad, APC backend is bad, use 
Reddis. Is that what we say? Do we ask people NOT to install the cheapest 
solutions but to install something that very few people know and willing to 
try? Oh, my... Is that real?

[1] 
http://highscalability.com/blog/2010/5/17/7-lessons-learned-while-building-reddit-to-270-million-page.html

I really think TYPO3 goes too far theoretical :(

-- 
Dmitry Dulepov
TYPO3 core&security team member
E-mail: dmitry.dulepov at typo3.org
Web: http://dmitry-dulepov.com/