Bug #23069
Epic #55070: Workpackages
Epic #55065: WP: Overall System Performance (Backend and Frontend)
Bottleneck in t3lib_tcemain
Status: | Resolved | Start date: | 2010-07-02 | |
---|---|---|---|---|
Priority: | Should have | Due date: | ||
Assigned To: | - | % Done: | 0% |
|
Category: | Performance | Spent time: | - | |
Target version: | 6.2.0 | |||
TYPO3 Version: | 6.2 | Is Regression: | No | |
PHP Version: | 5.2 | Sprint Focus: | ||
Complexity: |
Description
I think I spotted a perf issue in the TYPO3 code, slowing processes down in backend, when recursively copying page-trees with contents.
The code I take here as a reference is the one of release 4.4.0
t3lib/class.t3lib_tcemain.php:1008: method fillInFieldArray()
line 1056: There's a loop thru all the fields of all the tables
line 1111: for most of the fields (switch default) we call $this->checkValue()
line 1273: checkValue() calls $this->recordInfo() for the field
line 5981: recordInfo() executes a SQL query to get values for the field
As a result: for each page copied, for each table in TCA, for each field (most of them, the ones that are not system) in this table, there's an SQL query executed.
Even worst news: recordInfo() executes the SQL query using the given id. In some cases (and always when copying pages) the id is equals to something like NEWabcdef (that is, non numerical, and obviously not in database). Problem is, recordInfo() doesn't care about that, and executes the SQL query doing an intval() on the given id, resulting in a SQL query fetching values for uid='0' (which does not make sense).
In a structure where PHP and MySql are on the same server, it might not hurt much, but when SQL and PHP are on dedicated servers, network latency makes it incredibly slow (like minutes to copy pagetree containing 3~4 pages with some content elements)
(issue imported from #M14963)
History
#1 Updated by Jerome Schneider about 5 years ago
Original list message:
http://lists.typo3.org/pipermail/typo3-dev/2010-June/040884.html
#2 Updated by Xavier Perseguers about 4 years ago
- Target version changed from 4.6.0-beta1 to 4.6.0-beta2
#3 Updated by Xavier Perseguers almost 4 years ago
- Target version changed from 4.6.0-beta2 to 4.6.0-beta3
#4 Updated by Oliver Hader almost 4 years ago
- Target version changed from 4.6.0-beta3 to 4.6.0-RC1
#5 Updated by Xavier Perseguers almost 4 years ago
- Target version changed from 4.6.0-RC1 to 4.6.0
#6 Updated by Chris topher almost 4 years ago
- Target version changed from 4.6.0 to 4.6.1
#7 Updated by Chris topher over 3 years ago
- Target version changed from 4.6.1 to 4.6.2
#8 Updated by Steffen Gebert over 3 years ago
- Target version deleted (
4.6.2)
Speeding this up would be very good, of course...
#9 Updated by Ingo Schmitt over 1 year ago
- Is Regression set to No
Problem is still existing in 6.2 dev
#10 Updated by Ingo Schmitt over 1 year ago
- Category set to Performance
- Target version set to 6.2.0
- TYPO3 Version changed from 4.3 to 6.2
#11 Updated by Ingo Schmitt over 1 year ago
- Parent task set to #55065
#12 Updated by Mathias Schreiber 6 months ago
- Status changed from Accepted to Resolved
fixed with the static fieldinfo cache
#13 Updated by Simon Schaufelberger 6 months ago
Mathias, can you reference another issue or something where this is fixed?