Quite a bit hyped about recent findings for possible performance improvement in #TYPO3 routing. It seems that VariableProcessor could easily get a first level cache and reduce cpu time drastically (depending on rootline and route configurations).
In my case, there are 64.000 cache hits for just 46 variants that are usually calculated again and again, on every page load. That’s 40% of all cpu time of the request. 🤯💥
FYI: My scenario is an app basically, written in Extbase. So all this is ExtbasePluginEnhancer routes I am talking about. Not sure if that would affect page routing at all. Probably not.
Embrace change!
Currently upgrading an app from #TYPO3 8.7 up to 12 LTS, from PHP 7.3 up to 8.2. Non composer to composer. FTP to ssh+rsync via Gitlab CI job. First time unit and functional tests and frontend tests with codeception. Up to phpstan level 6 fixed. And much more.
A looot of work but things start to look really well now.
@mikestreety You may. So far, it took about two full weeks. But the coverage is still poor. Just some basic checks in place so far, but the infrastructure exists.
We are deploying via deployer/deployer and the rsync recipe of deployer contributors that is shipped along with depoyer for years now.
How are we doing tests? What is the exact question here? How we execute tests, how we write them? I am not able to share specific tests but I can outline and explain.
@mikestreety The docs are a bit awful. A lot of resources of v6 are valid for v7 but missing. Always a struggle to understand the feature set of deployer but IMHO still the most mature deployment tool. You can finde the recipe here: https://deployer.org/docs/7.x/contrib/rsync
I don't understand the warning though. It looks like there is an official rsync recipe but I fail to see it. However, contrib works very well.
@mikestreety As for the tests there are unit tests which don't test anything that involves DI or db.
I use functional tests to test services as a whole, and if needed, import db fixtures.
Codeception tests import a db with a complete structure but defined data set to be able to browse the frontend. Some pages, backend and frontend users, some content elements (usually just the plugins under test).
@pwaring I like that approach but that's not exactly what I am looking for. Without looking at runtime and user behavior, I'd like to know what methods my app depends most on. Like, what are the methods with the highest probability to be called based on their number of usages in the code.
