This is a live blog from the TYPO3 Developer Days in Malmö (Sweden). This is the page for friday, Juli 14th 2017.
If you like the live blog, please do not hesitate to share the URL. Thank you! At the end of the page there are some social media links, you can use to share.
Links to all days:
I hope you enjoy reading. If you have feedback, just let me know.
Hello … good morning from Malmö for the last day of the TYPO3 Developer Days.
Sorry for being late. It was the second very short night, though 😉
I am sitting now in the session of Susi Moog and Matthias Schreiber about performance optimizing wth blackfire.io.
Using a lot TypoScript conditions in TYPO3 results in an exponential growth if the caching table.
They are doing a live demo of blackfire.io, a online tool to measure performance and top find bottle necks.
It is doing basically the same as Xdebug / Cachegrind, but with a much nicer UI.
The core team defined rules regarding TYPO3, which are applied to the tool.
You can run blackfire.io not only in the browser, but also a command line agent.
It is possible to compare two rule sets. F.e. with eid request and xdebug and one time without. Result: Disable xdebug on production systems.
* Adds a header to the http request (or ENV var on CLI)
* PHP-extension checks signature
Cache what you can. Benni Mack will dive into this topic in the next section.
“Everything over 5 sek is static content”
* Consider Cache / Hit ratio
* CDN the sh**t out of your site
* Optimize your usergroups and cominations. The order of the usergroups matter.
* Screw modularity, whenever you => raises complexity
* Avoid (TypoScript) conditions => They are adding complexity and making things slower. Often it is better to set an ext_template in the database
* Remove all indexes from mySQL and set them individually for your project.
Basic version of blackfire.io is free, but all the nice things are in paid plans.
Susi and Matthes on stage
Q: Is is possible to run on a managed server?
A: The provider must in install the apache module.
For frontend perfomance analysis Google has a tool called lighthouse
Now there is the first break. I will be back the talk of Benni Mack regarding caching at 11:45 a.m.
BTW: There are crazy buildings in Malmö. Here a pricture from yesterday evening:
So we are back with the last session about caching.
How to pronounce caching: “Käsch” like the cash, nothing else
OH: “I love no_cache=1, everything works”
Goal is to serve content faster, more perfomant with less CPU time, memory, IO
But the hard thing is to get it under control
Caches are everywhere. CDN, Browser, php, Database … just to name a few
The TYPO3 caching framework is just a small part of all caches.
CDNs are distributing static content around the world.
Cache invalidation is different from cache clearing. It’s telling the server that an asset is invalid
Next the step of caching is the browser cache.
There is a second browser cache mechanism: the ETag. If something changes a new ETag is generated.
It is possible to deliver information only once with
There is no solution, if the timing was wrong. You cannot invalidate the browser cache.
Clearing Browser Cache is not an option. But TYPO3 can add the timestamp to an asset, which is update whenever a asset is updated. So it is a new asset for the browser and loaded like a new file
Now we have look at TYPO3 caching: The page cache
The “First Hit” is when TYPO3 has to do everything. The cached hit is delivered subsequently
The 1st is approx. 10 times slower than a cached hit.
Every variant of the page gets a seperate cache entry … also true for parameters like “utm-source” et al.
It’s possible to exclude parameters from cHash calculation, to avoid cache poioning
You do not want to use “no_cache=1”! It is possible to deactivate in TYPO3
But what about which never should never be cached like exchange data?
Analyse what should be cached…
If you have parts, that must not be cached, like a login => load it via ajax after generating the page
Another concept for caching are edge-side includes. TYPO3 is prepared, but not shipping it by default.
The caching framework does not solve all your problems.
* cache_core => compiled TCA etc.
* cache_hash => “dump everything in there”
* cache_pages => cHash related stuff
* cache_pagesection => complete compiled typoscript
* cache_rootline => for menus; access data, groups, time, for realurl
* fluid_template cache
* extbase_object => domain model information
* extbase_reflection => for injects et.al.
Caching backends are APC (in memory), database (lokal), filesystem (lokal)
More backends like Redis and Memcached are supported. These are seperate services.
If the hoster asks how much RAM you need for Redis, you can calculate it by looking at the size of cache_tables and add 25%.
Fix the issue, not the symptom and save the environment.
In five minutes the closing session starts … I’ll be back then 🙂
Oli Hader is entering the stage to say good bye.
The community thanks the sponsors who made this event also possible.
Thanks to the Hotel for the Icecreamchallenge … we broke the machine and they run out of icecream.
Thanks to the organizers!
Now the voting for the best dressed developer starts!
Here are the candidates:
Team Unicorn won the “Best Dressed Developer” competition. The price is a free ticket for T3DD18
Here the team of the enablers:
Thank you for reading and following the last days.
I hope, you enjoyed it.