Bug #30894
closed
Performance of WS Preview in extra Window is verrry slow
0%
Description
Hi,
we operate a huge site with about 26.000 TYPO3 pages and 18 workspaces for about 300 Usergroups. If the backend users want to preview a version of a edited page inside their workspace in the frontend, it takes up to 1:30 per "side" (preview view left i.e. and live view on right frame) to be generated. Also we are aware that caching is mainly disabled when using this function our SQL logging shows up to 29.000 (!!) queries firing on the database, asking all sorts of TS (sys_template) configurations (versioned ones) and getting read/write permissions of not only the page shown in the preview window but also the rootLine up etc.
My question: Is this huge amount of DB queries thought this way ? To my mind, the preview function only needs the acces rights to the WS of the page shown and the correct TS-Templates for that workspace. Respectively the configuration mentioned for the live workspace.
Did you test the workspace preview function with such huge amount of pages ?
thx 4 feedback, our backend users would really apprechiate it ;).
Files
Updated by Tolleiv Nietsch over 12 years ago
- Status changed from New to Accepted
we're aware of the issues (see workspaces/workflow newsgroup) but atm. everybody is very busy. If you have such large installations maybe you can find some budget or one of your developers for in-depth profiling? help is always very welcome
Updated by Steffen Gebert over 12 years ago
- File callgraph-interesting-part.png callgraph-interesting-part.png added
- File xhprof.zip xhprof.zip added
- full call graph
- XhProf run trace (the .typo3 file) - if you have it installed you could just copy it to your data directory and open it with ?run=4eebb0a27bead&source=typo3
- two HTML files from XhProf report
In my case it's the menu rendering, which is responsible for the immense execution time of >30sec. I use an HMENU displaying the first two levels of pages.
It results in a total of more than 1800 SQL queries, almost 1300 coming from t3lib_pageSelect::getMovePlaceholder (see callgraph-interesting-part.png).
Updated by Frank Gerards over 12 years ago
thx steffen, we tracked down the problem to menu rendering too - but the slow-down is only fe-parser is doing the "2nd half" namingly the live-workspace output, not the first preview workspace render ... also, when I disabled an iprocMenu - function we use (which indeed does a getRootLine), the render time went down from 48 to 16 secs... Seems the getRootline function seems to get all possible rootlines not the one from which the preview function is called...
Updated by Michael Stucki over 10 years ago
- Category changed from Usability to Workspaces
Updated by Michael Stucki over 10 years ago
- Project changed from 624 to TYPO3 Core
- Category changed from Workspaces to Workspaces
Updated by 
Updated by Benni Mack over 8 years ago
- Target version deleted (
7 LTS) - Is Regression set to No
Updated by Benni Mack over 4 years ago
- Status changed from Accepted to Needs Feedback
I believe this has been solved massively since TYPO3 v9, as we deal with lots of pages, and the middleware concept solves frontend requests in Workspace and non-workspace pages. Can you please confirm?
Updated by Benni Mack about 4 years ago
- Status changed from Needs Feedback to Closed
I will close this issue now due to lack of feedback, if you feel otherwise, let me know I will re-open this issue then.