Project

General

Profile

Actions

Bug #65634

closed

Backend performance improvement: SQL Indexes not used in printLogErrorMessages

Added by Christian Plattner about 9 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
DataHandler aka TCEmain
Target version:
-
Start date:
2015-03-10
Due date:
% Done:

100%

Estimated time:
TYPO3 Version:
6.2
PHP Version:
Tags:
Complexity:
easy
Is Regression:
No
Sprint Focus:

Description

When profiling a backend save request, a huge amount of time can be seen to be lost in DataHandler::printLogErrorMessages. It issues a SELECT statement which needs a full scan of the sys_log table on each save request!

explain SELECT * FROM sys_log WHERE type=1 AND userid=1 AND tstamp=1425974587 AND error<>0;
+----+-------------+---------+------+-----------------+-------+---------+-------+-------+-------------+
| id | select_type | table   | type | possible_keys   | key   | key_len | ref   | rows  | Extra       |
+----+-------------+---------+------+-----------------+-------+---------+-------+-------+-------------+
|  1 | SIMPLE      | sys_log | ref  | event,user_auth | event | 4       | const | 33398 | Using where |
+----+-------------+---------+------+-----------------+-------+---------+-------+-------+-------------+

However, if the additional field `action` would be added to the WHERE clause, the key "user_auth" could be used to speed up the query:

explain SELECT * FROM sys_log WHERE type=1 AND userid=1 AND tstamp=1425974586 AND error<>0 and action in (-1,0,1,2,3);
+----+-------------+---------+-------+-----------------+-----------+---------+------+------+-------------+
| id | select_type | table   | type  | possible_keys   | key       | key_len | ref  | rows | Extra       |
+----+-------------+---------+-------+-----------------+-----------+---------+------+------+-------------+
|  1 | SIMPLE      | sys_log | range | event,user_auth | user_auth | 6       | NULL |    4 | Using where |
+----+-------------+---------+-------+-----------------+-----------+---------+------+------+-------------+

So I would suggest adding the WHERE statement " and action in (-1,0,1,2,3)" for a performance boost


Related issues 1 (0 open1 closed)

Precedes TYPO3 Core - Bug #65697: [ad Bug #65634] Backend performance improvement: SQL Indexes not used in printLogErrorMessagesClosed2015-03-12

Actions
Actions #1

Updated by Gerrit Code Review about 9 years ago

  • Status changed from New to Under Review

Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/37692

Actions #2

Updated by Gerrit Code Review about 9 years ago

Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/37692

Actions #3

Updated by Gerrit Code Review about 9 years ago

Patch set 1 for branch TYPO3_6-2 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/37698

Actions #4

Updated by Andreas Fernandez about 9 years ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100
Actions #5

Updated by Christian Plattner about 9 years ago

May I add that your modification "AND action<256" did not help improving the performance:

explain SELECT * FROM sys_log WHERE type=1 AND action<256 AND userid=1 AND tstamp=1425974587 AND error<>0;
+----+-------------+---------+------+-----------------+-------+---------+-------+-------+-------------+
| id | select_type | table   | type | possible_keys   | key   | key_len | ref   | rows  | Extra       |
+----+-------------+---------+------+-----------------+-------+---------+-------+-------+-------------+
|  1 | SIMPLE      | sys_log | ref  | event,user_auth | event | 4       | const | 33532 | Using where |
+----+-------------+---------+------+-----------------+-------+---------+-------+-------+-------------+

Still, many rows have to be read. If you had added "AND action in (-1,0,1,2)", only 4 rows had to be read.

Follow-up bug report #65697 was created.

Actions #6

Updated by Benni Mack over 5 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF