Project

General

Profile

Actions

Bug #76581

closed

Backend Performance Flaws

Added by Raoul S almost 8 years ago. Updated over 1 year ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Performance
Target version:
-
Start date:
2016-06-10
Due date:
% Done:

100%

Estimated time:
TYPO3 Version:
6.2
PHP Version:
5.6
Tags:
performance, backend, large-site
Complexity:
Is Regression:
No
Sprint Focus:

Description

Hello,

i did some profling on the TYPO3 backend lately and i witnessed two huge performance flaws.
My focus has been on the page-speed of loading an editing-page for a generic content-element (type textmedia in my case), i.e. on the url:

/typo3/alt_doc.php?returnUrl=%2Ftypo3%2Fsysext%2Fcms%2Flayout%2Fdb_layout.php%3Fid%3D63%23element-tt_content-48&edit[tt_content][48]=edit

Here is what i've found:

1. When loading an editing-page TYPO3 builds a tree-structure (don't aks me what it stores) and sorts children of tree-nodes. This sorting is implemented with TYPO3\CMS\Backend\Tree\SortedTreeNodeCollection. When append() is called on the collection it first literally appends the element to the tail of the list and then restores the order with a call to $this->asort(), followed by call to $this->normalize() which iterates the entire list again. The first screenshot shows a callee-map which was generated by QCacheGrind. You can easily see that approximately 50% of execution time are spent in this sorting-method and its sub-routines. I was able to eliminate this bottleneck by pre-sorting the input-list to SortedTreeNodeCollection and then pushing the elements directly to the collection instead of calling append. This has the further advantage that the internal-order is always consistent.

2. After this bottleneck was resolved the TypoScript-Parser made up the next big block. It consumes roughly 36% of the remaining 50% execution time. The parsing-code is absolutely messy and i didn't want to invest much time in there fixing the actual algorithms. Instead i build a cache around the parser.

The two bottlenecks some up to 68% of overall execution time. The second screenshot shows the callee-map after i did some optimization. The appended diff-file entails all the tweaks i have done. This reduced the time-to-first-bit from roughly 4s to 1.3s for one single request which is still frustrating but better than nothing. I'm not into the official TYPO3 workflow for contributions, but i'm open to do some polishing on this changeset if somebody can guide me through the official workflow.

Callee Map before

Callee Map after

Regards
Raoul


Files

slow.png (84.5 KB) slow.png Callee Map before Raoul S, 2016-06-10 12:50
fast.png (155 KB) fast.png Callee Map after Raoul S, 2016-06-10 12:50
perf.diff (5.83 KB) perf.diff Performance Patch Raoul S, 2016-06-10 12:50

Related issues 4 (1 open3 closed)

Related to TYPO3 Core - Bug #75811: Backend speed decrease since 4.7Closed2016-04-20

Actions
Related to TYPO3 Core - Bug #75782: Massive performace problems in backend during workClosed2016-04-19

Actions
Related to TYPO3 Core - Epic #93547: Collection of problems with large sitesAccepted2021-02-19

Actions
Related to TYPO3 Core - Bug #99007: Workspace Overlays are slow when having multiple records queried at onceClosedBenni Mack2022-11-06

Actions
Actions

Also available in: Atom PDF