[TYPO3-english] Speed T3 4.4 vs. 4.5 + thoughts about response times and event-driven caching

[Boštjan Vlaovič]

Hello all,

> From: Stefano Cecere <scecere at krur.com>
>  how is 4.5 BE is "heavier and slower" for
> 	you

I understand that you are refering to BE, but I will write some words
about FE. Due to the performance problems of one of the new 4.5.2-based
site, we have performed some simple tests comparing it to 4.4.7. We have
run them on a virtual machine. I know that you would need a lot more, to
get the whole picture of the system, but I believe this is not really
neccessary, since tests were done "ad hoc".

Both T3 instalations were barebone, with TS:
page = PAGE
page.10 = TEXT
page.10.value = HELLO WORLD!

Here are the results measured from my laptop on 100 Mb/s connection to
the server. Cache was cleared at the server and client for each
measurement. I have used Chrome to measure times that were needed for
processing - I took notes of times that the client was waiting for the
response from the server.

4.4.7: 402, 363, 385, 410, 387, average 444 ms
4.5.2:  537, 578, 555, 487, 511, average 542 ms

I was suprised. I did not expect that T3 requires such fixed time-price.
Next, I measured the times at the problematic web site at the same
virtual host to load a page with couple of news lists (tt_news). Don't
be alarmed with times, it turned out that 3 other tt_news-related
extentions were causing performance problems, but nevertheless, here is
the comparison:

4.4.7: 6430, 6670, 6920, 6230, 6810, average 6612 ms
4.5.2: 6650, 7570, 6910, 7210, 7580, average 7184 ms

Quite a difference, I would say.

Next, I prepared some "Lorem Ipsum" text and mesured automaketemplate
and TemplaVoila:

T4.5.2-template: 684, 647, 591, 628, 641, average 638 ms
T4.5.2-templavoila: 706, 749, 754, 768, 739, average 743 ms

Difference will probably make me switch to automaketemplate or even
manualy configuration, since cca. 100 ms in average is quite big price
to pay.  I was quite impressed with the Backend Grid View Demo and I
love the idea that we could use TS (curently we use TV framework, but it
is probably not flexible enought to stick with it). I just have to see
what would be an equivalent of the FCE for the purpose of the "content
building" - two or three columns layout of the main content area that
can be inserted by the editor (all references very welcome!).

During this optimization effort I thought a lot about caching. Now we
use /cachemgm, //crawler, //nc_staticfilecache,/ /ttnewscache_clearlike,
and //ttnewscache./ Later two have some problems in mentioned versions
of T3 that we have not investigated, jet. I am wondering why cache
regeneration is time-driven and not event-driven? We would love to have
all or selected part of the content, that can be stored in such way, in
static files. We want to proactively change cache and static files when
the content on this pages changes (and only those) and make sure, that
_all_ our costumers will access the cached version (even the one that
accesses the page first). Instead of cca. 600 ms, we would get response
times in the range less than 5 ms (waiting time for main content only).
Additionally, If config.cache_period is 3600 s, that means that each
hour one of the customers has to wait (ok, in this example for 600 ms,
but this times could be higher, as we all know). Additionaly, when we
change some tt_news item, many pages change and visitor would be waiting
on more than one occasion - even if we manage to setup selective Single
view page clearing, List views that include this particular item can be
on many locations. I understand that it is wise to clear cache
time-to-time, but that is another issue.

In such visitor-based or time-based "recaching setup" server's CPU  is
always occupied with tasks that can be avoided or at least spread over
time. Additionally, we can not achieve that all of our visitors access
the static (or cached) content - unles we manually reload all effected
pages right after the update. Requirements on the server hardware could
drop in big installations, right? I know that cache clearing and
regeneration is not a simple tasks, but T3 implementation already covers
clearing for most situations (extentions with "Single view" approach are
excluded, I suppose ;-). Wouldn't be nice if we could setup T3 that it
regenerates the cache instead of just clearing it? Did I miss something
and this functionality is already available?

Kind Regards and thank you to those who are citing only relevant parts,

Bostjan

-- 
*Boštjan Vlaovič* | bostjan.vlaovic at 4s.si
<mailto:bostjan.vlaovic at 4s.si> | GSM: +386 41 769 386
4S, svetovanje in razvoj, d.o.o. | Koroška cesta 78  | 2000 Maribor |
http://www.4s.si/