Feature #19513

Instantiate time tracker as null object if not really required

Added by Oliver Hader about 11 years ago. Updated over 9 years ago.

Status:
Closed
Priority:
Should have
Category:
Communication
Target version:
-
Start date:
2008-10-28
Due date:
% Done:

0%

PHP Version:
5.2
Tags:
Complexity:
Sprint Focus:

Description

In the TYPO3 front-end an instance of t3lib_timeTrack is created in the variable $TT. During the front-end rendering process the time required to parse and execute several scripts and modules are stored using this object.

However, that object is not required in production environments and reduces performance a lot. The solution would be to use a null object in general and only use the current time tracker if a website admin has the admin panel enabled in the front-end to get detailed information about the rendering process.

(issue imported from #M9657)

9657v0.diff View (12.7 KB) Administrator Admin, 2008-10-31 18:59

9657v1.diff View (14.3 KB) Administrator Admin, 2008-11-05 01:27

9657v2.diff View (9.54 KB) Administrator Admin, 2009-08-31 16:25

9657v3.diff View (9.16 KB) Administrator Admin, 2009-09-02 13:12


Related issues

Duplicated by TYPO3 Core - Bug #20755: Frontend rendering is slowed down by timetracking Closed 2009-07-14

History

#1 Updated by Oliver Hader about 11 years ago

On searching the Core for t3lib_timeTrack I found only one strange place where this is used (except the front-end rendering):
typo3/sysext/rtehtmlarea/htmlarea/plugins/SpellChecker/spell-check-logic.php

However, I don't know what effect the time tracker has in RTEhtmlarea...

#2 Updated by Dmitry Dulepov about 11 years ago

Null object should have the same methods other PHP error will occur.

#3 Updated by Ingo Renner about 11 years ago

of course, we'll just introduce a new interface that both the TT that we have right now and the new null object do implement (with the same methods that TT has right now)

#4 Updated by Ingo Renner about 11 years ago

here's a version "0". This thing works but there's a significant problem with the whole time tracking:

The point in EXT:cms/tslib/index_ts.php where TT is instantiated is very early in the script. The only point where the information collected by TT is used is the adminpanel. Now whether the admin panel gets shown is decided way further down and you can't use the same condition used there to decide whether to use the real TT or the null TT at the point where TT is instantiated...

Any suggestions?

#5 Updated by Ingo Renner about 11 years ago

So here's v1 which decides which time tracker to load by checking for a cookie. That cookie gets set when the Typoscript section in the adminpanel gets opened.

For now the cookie setting/unsetting is done in PHP, but could also be moved to JS as soon as we have a dedicated admin panel JS class

#6 Updated by Dmitry Dulepov over 10 years ago

The patch has also non–functional changes (like added "public" definitions) that should be left out. In addition it should be fixed to follow CGL ("{}" is not allowed).

Having an extra cookie is probably not good. I suppose we might look how TT is used and get rid of early messages. I doubt they are really useful. They were useful before real profilers appeared but now TT is more use for content rendering tracking than for profiling. So we can get rid of early TT usage and avoid cookies too.

#7 Updated by Christian Kuhn over 10 years ago

I'm personally fine with another cookie that will only be set if admin panel is enabled. Usual FE users won't ever get this cookie set.

Another way to enable TT early in the script is to do the same check for _COOKIE('be_typo_user) like it's done for the BE_USER instantiation later in the script. This however might lead to false positives (cookie set, but BE user not "really" logged in). I could live with that as well.

A non representative, quick test showed me a positive performance impact of up to 8% for cached pages, I think that's worth the hassle.

#8 Updated by Ingo Renner over 10 years ago

actually the check for the BE user should be enough. I can't remember exactly why I added a new cookie back then

#9 Updated by Christian Kuhn over 10 years ago

@Ingo: With "check for the BE user" you mean: "Check if the be_typo_user cookie is set"?

#10 Updated by Rupert Germann about 10 years ago

I'm preparing a patch with a simplified BE_USER check.
the current v1 patch also causes a problem with realurl because function debug_typo3PrintError() is called which is now protected.

#11 Updated by Rupert Germann about 10 years ago

added v2 of the patch.
changes compared to v1:
- the check for a logged in be_user is done by checking the be_user cookie
- I droppend the interface class. Benchmarks showed that it is faster without (little bit)

#12 Updated by Rupert Germann about 10 years ago

benchmark results:

cached pages:
trunk: 293.83 trans/sec 100%
patched: 308.95 trans/sec 105%

uncached pages:
trunk 34.47 trans/sec 100 %
patched 37.03 trans/sec 107 %

Details:

cached pages:

trunk r5856
---------------------------------------------------------------------
Transactions: 17762 hits
Availability: 100.00 %
Elapsed time: 60.45 secs
Data transferred: 439.07 MB
Response time: 0.05 secs
Transaction rate: 293.83 trans/sec
Throughput: 7.26 MB/sec
Concurrency: 14.96
Successful transactions: 17762
Failed transactions: 0
Longest transaction: 0.43
Shortest transaction: 0.00

patched 9657v2
---------------------------------------------------------------------
Transactions: 18534 hits
Availability: 100.00 %
Elapsed time: 59.99 secs
Data transferred: 458.64 MB
Response time: 0.05 secs
Transaction rate: 308.95 trans/sec
Throughput: 7.65 MB/sec
Concurrency: 14.97
Successful transactions: 18534
Failed transactions: 0
Longest transaction: 0.46
Shortest transaction: 0.00

uncached pages:

trunk r5856
-------------------------------------------------------------
Transactions: 2086 hits
Availability: 100.00 %
Elapsed time: 60.52 secs
Data transferred: 53.89 MB
Response time: 0.43 secs
Transaction rate: 34.47 trans/sec
Throughput: 0.89 MB/sec
Concurrency: 14.93
Successful transactions: 2086
Failed transactions: 0
Longest transaction: 1.49
Shortest transaction: 0.07

patched 9657v2
-------------------------------------------------------------
Transactions: 2227 hits
Availability: 100.00 %
Elapsed time: 60.14 secs
Data transferred: 57.53 MB
Response time: 0.40 secs
Transaction rate: 37.03 trans/sec
Throughput: 0.96 MB/sec
Concurrency: 14.92
Successful transactions: 2227
Failed transactions: 0
Longest transaction: 1.08
Shortest transaction: 0.07

#13 Updated by Rupert Germann about 10 years ago

committed v3 patch to trunk rev 5881

Also available in: Atom PDF