Bug #28481

sys_log insertions should not take processing time

Added by Raphaël Riel over 10 years ago. Updated over 8 years ago.

Should have
Start date:
Due date:
% Done:


Estimated time:
TYPO3 Version:


Currently, every error/warning sent to the sys_log table is done via a regular "insert into" which consume valuable rendering time waiting for mysql_query() to complete.

Three possible solutions proposed:
  1. Use "INSERT DELAYED INTO" to reduce time consumed by the insertion.
  2. Buffer all insertions and make inserts upon request termination (after sending output to web browser). I think this is how Extbase's persistance manager works.
  3. Add the option to write all theses entries in php/apache's regular error_log file.

I think 3rd option is a must since errors should reside in error_log.

Related issues

Related to Logging Project - Task #46616: Evaluate usage of INSERT DELAYED INTO for DatabaseWriterRejected2013-03-23


Updated by Steffen Gebert over 10 years ago

There was a new Logging Improvements project kickstarted at the Developer Days. You brought some up very good ideas!

Would you like to join that project? We will have another real kickstart meeting within the next few weeks (2-4 weeks, I assume). Would be really great!


Updated by Mario Rimann about 10 years ago

@Steffen: What of the proposed changes should be implemented in the meantime until a full-blown logging system has evolved?


Updated by Steffen Müller about 10 years ago

Here's my opinion on your suggestions:

1) Is "INSERT DELAYED INTO" generic SQL or proprietary implementation? It would need to be DBAL compatible to make it into TYPO3 core.
2) Does not work if script execution stops unexpectedly (e.g. on PHP fatal). Logging is expected to succeed, even if something crashes badly afterwards. This argument is also valid for 1)



class brokenExample {

        public function fail() {

        public function __destruct() {
                echo 'Class ' . __CLASS__ . ' was terminated successfully';

$test = new brokenExample();

PHP Fatal error:  Call to undefined function undefinedFunction() in /tmp/test.php on line 6
PHP Stack trace:
PHP   1. {main}() /tmp/test.php:0
PHP   2. brokenExample->fail() /tmp/test.php:15

3) Introducing yet another configuration option was the common practice and this practice resulted in a confusing configuration overflow. We should catch all these nasty unflexible stuff and create one clean API to rule them all (TM).

Would you like to join the logging project team?


Updated by Steffen Müller about 10 years ago

  • Project changed from TYPO3 Core to Logging Project
  • Category deleted (Performance)

Updated by Steffen Müller almost 9 years ago

item 3) is possible with 6.0 though not 100% resolved.

With the new Logging API in 6.0 you can configure to write all logs to PHP error_log.

Still this Logging API needs to be integrated (replace all old log functions and calls). This is targeted for 6.1/6.2.


Updated by Georg Großberger over 8 years ago

With the new Logging API, this becomes a feature of the actual writer.

A database writer cannot simply do that. Using MySQLs "DELAYED" keyword is deprecated since 5.6.6 [1] and has been targeted at MyISAM tables anyway, which are supposed to be succeded by InnoDB tables.

NoSQL writers offer the simplest solution for this, as they work asyncronously be default.

The only way to make everything work in the background in PHP, would be using pthreads [2], but this feature still has a long way to go to become mainstream PHP, if ever.

[1] http://dev.mysql.com/doc/refman/5.6/en/insert-delayed.html
[2] http://www.php.net/manual/en/book.pthreads.php


Updated by Steffen Müller over 8 years ago

I reject this issue, because:

1) INSERT DELAYED is deprecated. See #46616 and http://dev.mysql.com/doc/refman/5.6/en/insert-delayed.html
2) can lead to severe drawbacks
3) is matter of configuration


Updated by Steffen Müller over 8 years ago

  • Status changed from New to Rejected

Also available in: Atom PDF