Task #54701

Epic #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

Added by Felix Oertel almost 6 years ago. Updated about 2 years ago.

Status:
Closed
Priority:
Should have
Assignee:
Category:
Caching
Target version:
-
Start date:
2014-01-02
Due date:
% Done:

0%

TYPO3 Version:
6.2
PHP Version:
Tags:
Complexity:
hard
Sprint Focus:

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


Related issues

Related to TYPO3 Core - Bug #55028: Static TS must be available even when there is no page UID Closed 2014-01-15
Related to TYPO3 Core - Task #54813: BackendConfigurationManager figures out wrong pid New 2014-01-07
Related to TYPO3 Core - Task #86262: Deprecate FE TypoScript processing in BE Rejected 2018-09-15
Duplicated by TYPO3 Core - Task #54571: Extbase: Avoid TS parsing in BE if not necessary Closed 2013-12-22
Duplicated by TYPO3 Core - Bug #55023: List Module in Backend is very slow due to Extbase's Typoscript parsing Closed 2014-01-15

History

#1 Updated by Gerrit Code Review almost 6 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

#2 Updated by Gerrit Code Review almost 6 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

#3 Updated by Lorenz Ulrich almost 6 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.

#4 Updated by Gerrit Code Review almost 6 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

#5 Updated by Gerrit Code Review almost 6 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

#6 Updated by Ernesto Baschny almost 6 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.

#7 Updated by Felix Oertel almost 6 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.

#8 Updated by Gerrit Code Review almost 6 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

#9 Updated by Gerrit Code Review almost 6 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

#10 Updated by Felix Oertel almost 6 years ago

Actually this patch now has become an extbase-only patch. :) so someone might just move that ticket ...

#11 Updated by Gerrit Code Review almost 6 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

#12 Updated by Gerrit Code Review almost 6 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

#13 Updated by Gerrit Code Review almost 6 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

#14 Updated by Gerrit Code Review almost 6 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

#15 Updated by Felix Oertel almost 6 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.

#16 Updated by Oliver Klee almost 6 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.

#17 Updated by Felix Oertel almost 6 years ago

Oliver Klee wrote:

If we still need this number

We will - anyway - need it, yes. ;)

#18 Updated by Alexander Stehlik almost 6 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:

  1. 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?)
  2. 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.

#19 Updated by Marc Bastian Heinrichs almost 6 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.

#20 Updated by Helmut Hummel almost 6 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.

#21 Updated by Gerrit Code Review almost 6 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

#22 Updated by Ingo Schmitt almost 6 years ago

  • Parent task set to #55079

#23 Updated by Wouter Wolters almost 5 years ago

  • Status changed from Under Review to New
  • Target version deleted (6.2.0)

#24 Updated by Susanne Moog about 2 years ago

  • Blocked by deleted (Task #54813: BackendConfigurationManager figures out wrong pid)

#25 Updated by Susanne Moog about 2 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.

#26 Updated by Susanne Moog about 2 years ago

  • Related to Task #54813: BackendConfigurationManager figures out wrong pid added

#27 Updated by Christian Kuhn about 1 year ago

  • Related to Task #86262: Deprecate FE TypoScript processing in BE added

Also available in: Atom PDF