Bug #52374
Epic #55070: Workpackages
Epic #55065: WP: Overall System Performance (Backend and Frontend)
Bug #52949: Speed decrease since 4.5
Editing a sys_filemount is very slow
| Status: | New | Start date: | 2013-09-30 | |
|---|---|---|---|---|
| Priority: | Should have | Due date: | ||
| Assigned To: | Mathias Schreiber | % Done: | 0% |
|
| Category: | Performance | Spent time: | - | |
| Target version: | - | |||
| TYPO3 Version: | 6.2 | Is Regression: | No | |
| PHP Version: | 5.5 | Sprint Focus: | ||
| Complexity: |
Description
When editing a filemount as popup window from the edit form of a be_group, the form takes about 9 sec to show up.
xhprof shows that this method is responsible for this amount of time:
TYPO3\CMS\Core\Resource\Service\UserFileMountService::renderTceformsSelectDropdown
Info¶
- My list of sys_filemounts contains 2600 entries
- I see 20 calls to TYPO3\CMS\Core\Resource\Folder::getSubfolders taking 4,728,752 ms
- After 2nd recursion, still 298 calls to TYPO3\CMS\Core\Resource\Service\UserFileMountService::getSubfoldersForOptionList taking 4,505,079 ms
Actually there is much recursion but it's always TYPO3\CMS\Core\Resource\Folder::getSubfolders that eats so much time
History
#1 Updated by Markus Klein over 1 year ago
- Parent task changed from #52304 to #52949
#2 Updated by Mathias Schreiber 6 months ago
- Status changed from New to Needs Feedback
- Assigned To set to Mathias Schreiber
Hi Xavier,
I just have 600 folders, but for me it's fine on master.
Is this done?
#3 Updated by Xavier Perseguers 6 months ago
- TYPO3 Version changed from 6.1 to 6.2
- PHP Version changed from 5.3 to 5.5
Updated the PHP and TYPO3 version.
Using a real life server (that is, not with SSD but quite powerful anyway):
- 3522 directories (8 at the 1st level)
- about 27 sec to show up the edit form (edit pencil for a filemount record)
This is still not usable.
The same using SSD (development environment):
- 2250 directories (8 at the 1st level)
- about 3 sec to show up the edit form
This time it's totally OK of course but users are usually not using a development machine with local MySQL and SSD.
Didn't test with master, 6.2 is less than 1 year old and is a LTS with big projects so I'd like to see improvements for it if possible (we shouldn't forget that 6.2 is even not yet used by many bigger websites).
#4 Updated by Alexander Opitz about 1 month ago
- Status changed from Needs Feedback to New
#5 Updated by Xavier Perseguers about 1 month ago
Did not debug again but this huge amount of time just appeared again this morning while configuring a Dropbox storage. Since every directory is searched for recursively, it took minutes (!) to fetch the structure of directories in my Dropbox account (total of about 50 directories?). So locally this may be slow but with remote storages this is even worse.