Improve performance of tracker by speeding up dependency injection PHP DI

[tsteur]

See profile of a tracker request below.

Around 70% (105 out of 150ms in total) of the time is spend in exclusively in the first 5 methods related to DI.

Typically, methods are executed very often are over-reported in Xhprof so it might be more like 30% or so but that would be still quite a lot of time.

Not sure if there's anything we can do ourselves in terms of configuring it, or if we would need to tweak PHP DI (which we could consider paying for if there's anything that can be done).

see https://php-di.org/doc/performances.html

Maybe enabling definition cache and/or compilation is something we can look into. Any solution would need to support https://developer.matomo.org/guides/multi-tenants where a Matomo runs with hundreds or thousands of different config files / instances. Seems we could eg configure a cache directory per account for example.

[tsteur]

Enabling definition cache via apcu locally made the time spent in these methods up to 5 times faster for me (without xhprof might be only 3 times).

[rr-it]

@tsteur Is this performance data from a productive install e.g. composer install -o --no-dev?

---

Composer optimization

How about using the composer optimization classmap-authoritative to boost the performance?

See: https://getcomposer.org/doc/articles/autoloader-optimization.md#optimization-level-2-a-authoritative-class-maps

Activate on install: composer install --no-dev --classmap-authoritative

Or afterwards via: composer dump-autoload --no-dev --classmap-authoritative

Or add to composer.json

{
    "config": {
        "classmap-authoritative": true
    }
}

---

Performance in general

System: PHP-FPM with OPCache

Track page view:

Server response time under 60 ms - thats pretty awesome! :rocket:

• 25 ms: server stack
• 35 ms: Matomo and database

For comparison: simple call to php-file

<?php
echo 'test';

[sgiehl]

@rr-it Thanks for the suggestion. Unfortunately we can't easily use classmap-authoritative. For all classes in core that might not be a problem, but when a new plugin is installed, those classes would be missing in the class map. So we would need autoloading nevertheless.