Task #54701
closedEpic #55070: Workpackages
Epic #55065: WP: Overall System Performance (Backend and Frontend)
Epic #55656: Optimize overall Extbase performance
Story #55079: review Extbase caching for frontend and backend
Cache global TypoScript template in backend
0%
Description
Hey guys,
when profiling, why extbase backend modules are too slow, we found that parsing the TypoScript took up a hole lot of time at every single request. The TypoScript is not cached in the backend, because the condition for caching relys on $GLOBALS['TSFE']->all.
If we exchange that for a condition on the TemplateService instead, it should properly cache the TypoScript.
I would be interested in some oppinion about wether or not we have to care for things that might invalidate the cache.
regards, foertel
Updated by Gerrit Code Review over 10 years ago
- Status changed from New to Under Review
Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/26618
Updated by Gerrit Code Review over 10 years ago
Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/26618
Updated by Lorenz Ulrich over 10 years ago
if ($cc = $this->getCurrentPageData()) {
also delivers the page data if the page is called with &no_cache=1, while
if ($GLOBALS['TSFE']->all) {
doesn't. I'm not sure if that behaviour is a problem.
Updated by Gerrit Code Review over 10 years ago
Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/26618
Updated by Gerrit Code Review over 10 years ago
Patch set 4 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/26618
Updated by Ernesto Baschny over 10 years ago
My stomach feeling is that this is not the right solution, because this particular API is not intended to be used that way. This is expected to be called from the frontend context only and thus having a working and reliable TSFE set up.
Since Extbase needs this in the backend, I think the least disturbance in this area would be to improve on the "dummy-TSFE" creation process in Extbase to make sure TSFE->all is also available for later caching.
Just a random thought without digging concretely into the code. I fear that we cannot predict the side effects of the proposed patch so far.
Updated by Felix Oertel over 10 years ago
Hey Ernesto,
i updated the code accordingly. At the moment there is no "dummy-TSFE" in backend context, but I think it's allright to set up TSFE->all for this.
At the moment it simply does not work, because of the blocking issue #54813.
So we will have to fix that first.
Updated by Gerrit Code Review over 10 years ago
Patch set 5 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/26618
Updated by Gerrit Code Review over 10 years ago
Patch set 6 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/26618
Updated by Felix Oertel over 10 years ago
Actually this patch now has become an extbase-only patch. :) so someone might just move that ticket ...
Updated by Gerrit Code Review over 10 years ago
Patch set 7 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/26618
Updated by Gerrit Code Review over 10 years ago
Patch set 8 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/26618
Updated by Gerrit Code Review over 10 years ago
Patch set 9 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/26618
Updated by Gerrit Code Review over 10 years ago
Patch set 10 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/26618
Updated by Felix Oertel over 10 years ago
First of all: thanks to all of you for commenting. I would like to move the discussion from gerrit to forge to keep some overview.
Alexander Stehlik
This is definitely a breaking change. Before the templates included in the first root page were loaded. Now they are not available any more.
That is right. I am not entirely sure, but I think this was wrong in the first place. In a module without pagetree no page is present and thus no TypoScript from the pagetree should be loaded.
Benjamin Mack
can we also please get rid of the constant and the function "getDefaultBackendStoragePid()" as well in order to keep the code clean?
Oliver requested this constant and I thought it might make sense to use it instead of writing some magical integer into the code.
Removing the method would need some more inspection. I think it's there between some interface-dependency and difference between backend- and frontend-configurationManager.
Updated by Oliver Klee over 10 years ago
If we still need this number, we should keep it as a constant instead of a magic number. Magic numbers are no-gos as far as readability is concerned.
Updated by Felix Oertel over 10 years ago
Oliver Klee wrote:
If we still need this number
We will - anyway - need it, yes. ;)
Updated by Alexander Stehlik over 10 years ago
I think Marc Bastian Heinrichs' idea is also quite interesting for generating the configuration in the Backend (quote from https://review.typo3.org/26675/):
I would like to see this change reverted and have a better solution than having to use ext_typoscript_setup.txt, which is inofficially deprecated since ages. E.g. "registering" the backend context page id for a separated module where the typoscipt is integrated. By this solution the TS for BE and FE is separated and could be parsed in the single context.
Basically the only configuration that is independent from the Pagetree is Extension configuration or LocalConfiguration.
As far as I can see we have these contexts where we do not have a PID:
- Scheduler tasks
- Backend Modules without Pagetree
- Command line controllers
So what I suggest are two possibilities to influence the building of the TypoScript from the Pagetree in these cases:
- add an Extension setting (for the ExtensionManager) where a default PID can be set from which the configuration for pageless contexts should be build (maybe there can be one setting per case - scheduler, Backend Module, Command line?)
- allow passing the PID from which the configuration should be read to the ConfigurationManager so that Extensions can provide their own way to determine the PID from which the configuration should be build.
I'm looking forward to your feedback.
Updated by Marc Bastian Heinrichs over 10 years ago
The new solution for all the frontend typoscript hassle in backend modules should also have in mind getting rid of all the ext_typoscript_setup.txt files in core backend modules, which need to work also without a pagetree.
So we should discuss, if also registering a typoscript file directly for backend modules could be a way to handle this.
Because atm all the typoscript from the ext_typoscript_setup.txt files in core backend modules are parsed and available in frontend without need.
Updated by Helmut Hummel over 10 years ago
Marc Bastian Heinrichs wrote:
So we should discuss, if also registering a typoscript file directly for backend modules could be a way to handle this.
I like this idea! Alternative would be to assume a certain location for extbase extension backend TypoScript-Configuration, e.g. Configuration/Backend/Module.ts
We could then load and cache the configuration for all modules of one extension.
Because atm all the typoscript from the ext_typoscript_setup.txt files in core backend modules are parsed and available in frontend without need.
Agreed.
Updated by Gerrit Code Review over 10 years ago
Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/26876
Updated by Wouter Wolters over 9 years ago
- Status changed from Under Review to New
- Target version deleted (
6.2.0)
Updated by Susanne Moog almost 7 years ago
- Blocked by deleted (Task #54813: BackendConfigurationManager figures out wrong pid)
Updated by Susanne Moog almost 7 years ago
- Status changed from New to Closed
As the proof of concept and the discussion showed simply caching the TypoScript won't be possible. I'll close this ticket now, as for the underlying performance issue probably a new configuration concept should be invented.
Updated by Susanne Moog almost 7 years ago
- Related to Task #54813: BackendConfigurationManager figures out wrong pid added
Updated by Christian Kuhn almost 6 years ago
- Related to Task #86262: Deprecate FE TypoScript processing in BE added