Feature #81389
closedEpic #55070: Workpackages
Epic #55065: WP: Overall System Performance (Backend and Frontend)
Epic #55656: Optimize overall Extbase performance
Task #57594: Optimize ReflectionService Cache handling
Injected ReflectionService without call to initialize/shutdown
0%
Description
There are different classes which get the ReflectionService via inject but do not call initialize and shutdown, which results in cache savings for other Extbase Extensions afterwards.
Following scenario:
I've in frontend a fluid page which uses ViewHelpers and an extbase plugin. On my example page is dynamic content and so it isn't cached.
- The AbstractViewHelper gets the ReflectionService injected, no initialize and shutdown is called.
- AbstractViewHelper->registerRenderMethodArguments() calls getMethodParameters
- As no data is in cache, it is generated and in ReflectionService dataCacheNeedsUpdate is set to TRUE;
- The Extbase Extension is called, ReflectionService is initialized but dataCacheNeedsUpdate stays TRUE
- On calling ReflectionService Shutdown the loaded (and not changed) cache is written to the cache ... which isn't needed.
- Later AbstractViewHelper->registerRenderMethodArguments() calls again getMethodParameters which again do not found some parts, as the initialize of the ExtbaseExtension overwrote the data.
- Again ReflectionService dataCacheNeedsUpdate is set to TRUE;
- Now Second part of my Extension is started with initialize/shutdown
- And again a normally clean cache is written again as dataCacheNeedsUpdate is TRUE
Setting dataCacheNeedsUpdate to false in ReflectionService->initialize() helps here (the multiple cache loading should be handled in parent task)
Updated by Markus Klein over 7 years ago
Sounds really weird. Any improvement is very welcome.
Updated by Alexander Opitz over 7 years ago
I think I try to make an extension which XClasses the ReflectionService, so changes could be tested beforehand.
Updated by Susanne Moog about 7 years ago
- Status changed from New to Needs Feedback
Please test your scenario after the latest changes in Extbase Reflection.
Updated by Alexander Opitz about 7 years ago
- Description updated (diff)
- Status changed from Needs Feedback to New
No, it doesn't fix the issue.
Updated by Alexander Opitz about 7 years ago
- Status changed from New to Closed
- Assignee deleted (
Alexander Opitz) - Target version changed from Candidate for patchlevel to 9.0
I was a bit fouled by a wrong symlink ... looked inside an old version.
Reading again, yes, this looks really better and solves this issue.