TYPO3 Core

I wanted to add that this is "NOT" a cache issue is and other people have the same problem from the 6.x version of TYPO3

Harald

Hi Harald,

I've had similar problems, but it was not a Typo3 issue. It was a configuration issue of MySQL. Which version of MySQL do you use? I've had problems after an Upgrade from MySQL 5.1 to 5.5. Insert Queries to innodb tables were very slow!

Had to set:

    innodb_flush_log_at_trx_commit = 0

Hi Martin!

Thank you for your recommendation. I started the project with MySQL 5.5!

Unfortunately I have no way to access the mysql.ini. This is managed by my TYPO3-hoster.

This hoster in a TYPO3 specialist and only hosts TYPO3 projects. He is also well known. I think it will fit regarding this setting.

Thank you very much

Harald

Hi Martin,

thank you for the recommendation regarding MySQL settings.
We are also affected by this issue.
The Hoster disabled the option and the page generation is much faster.

So, is this an TYPO3 Issue that should be solved or a suboptimal configuration?

Henrik Ziegenhain wrote:

So, is this an TYPO3 Issue that should be solved or a suboptimal configuration?

Hi Henrik,

Glad that your problems are solved now! I've had to spend a lot of time, to figure this out. ;)

No it's more a suboptimal/wrong configuration than a Typo3 Error! Typo3 4.5 instances on such systems are also very slow.

I've had this problem on a debian Wheezy server. It's possible that only this systems are 'affected'... I don't know.

Hi Martin,

our hoster said, it has to do with ext4 filesystem.
If I remember right: every database action is stored in the filesystem for a better data integrity.
Generating a non-cached page took ~30sec, a cached page was rendered in about 300ms.

Henrik Ziegenhain wrote:

Hi Martin,

our hoster said, it has to do with ext4 filesystem.
If I remember right: every database action is stored in the filesystem for a better data integrity.
Generating a non-cached page took ~30sec, a cached page was rendered in about 300ms.

Ohh sound's interesting! So the main problem is not the MySQL Setting innodb_flush_log_at_trx_commit?
Do you know, what has to be done to fix the ext4 issue?

I think the combination of ext4 and innodb_flush_log_at_trx_commit was the problem.

Sorry, but I am not so familiar with those technical issues.

Yes.. for me, it's not a Typo3 Issue!

As Hanrik pointed out, it's a ext4 issue.
Truncating table queries were also very slow! Clear Typo3 Cache took very long.
Had to disable write barriers of the mounted ext4 hd to fix this (https://wiki.archlinux.org/index.php/Ext4).

So changing MySQL Setting innodb_flush_log_at_trx_commit fixes only one part of the Problem.

Hello,

do you really know WHAT innodb_flush_log_at_trx_commit does? It stops writing the log for just 1 second. So...if something gets wrong your data gets lost if you set this value to 0. I know...this options makes MySQL about 50% faster with inserts. This is pretty cool and works only with InnoDB (Mainly Cache tables of TYPO3). So this option is NOT the problem. This options gives you some more performance in general, but not only regarding a special TYPO3-Version. With this option you can speed up TYPO3 4.6, also.

So please: Do NOT turn off this options. It is for safety reasons and has nothing to do with this problem here. Sure, it speeds up your webpage, but it does NOT solve your problem.

Stefan

To say "This is not a TYPO3 problem" is easy to say. But in my opinion there are many changes within TYPO3 just at starting period. Just one example: You have changed the load of TCA. Please check your profiling against Utility\ArrayUtility::arrayExport($GLOBALS['TCA']); This takes 1,1 Second on my local machine with SSD. What do you think what will it take on a HDD? 3 or 4 seconds?
I will create a patch for this here in this ticket and you all can check if it helps a little bit.

Stefan

The output of "cat /proc/meminfo" may help to see if this is more a problem of the server.

@Stefan, don't get me wrong, I am not opposing working on performance in the 6.x branch, as I am sure we have still lot to do in this area which was a bit neglected lately. The original reporter mentioned that the problem was ext4 + the mysql setting, which is what "TYPO3 cannot do anything about it" (except maybe document some "known pitfals").

Great that you took some time to work on the performance front by profiling and getting into detail, Stefan. I support this work and hope others can jump in. I'll try to work on that area too a bit.

@Stefan,

Don't know if Herald's performance issues are solved now. I've had similar problems and for me it was obvious that the problem was on MySQL/Server side. If a simple insert query takes some seconds instead of milliseconds, there has to be something wrong with the server configuration/setup. It's possible that disabling writing barriers on ext4 systems will do the trick and you don't have to disable innodb_flush_log_at_trx_commit anymore. Have not tested this..

But improving Typo3 performance in general is always a good idea!.. ;)

Patch set 2 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/23969

Patch set 3 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/23969

Patch set 4 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/23969

+1 on Ernesto's analysis innodb_flush_log_at_trx_commit = 2 , we set this, too.

Patch set 1 for branch TYPO3_6-1 has been pushed to the review server.
It is available at https://review.typo3.org/24051