search

NicoHood / grav-plugin-matomo

Integrates Matomo analytics into Grav CMS
GNU General Public License v3.0
6 stars 1 forks source link

PHP tracking first page reload is slow #1

Open NicoHood opened 3 years ago

NicoHood commented 3 years ago

On a website with not much traffic the first page load in the morning takes a bit longer. Possible reasons:

This does not happen with the plugin disabled. It could be solved with an async task, as the execution of the tracking is not critical. But how to do that properly?

klamann commented 2 years ago

Hi @NicoHood, I have the same issue with PHP tracking. Had to deactivate the plugin, because it caused frequent downtimes.

I'm not sure why matomo fails to process the request in a reasonable amount of time, but we could at least try to mitigate the issue. My preferred solution would also be an asynchronous request, but I don't know if there's a good way to do this in PHP. Probably with pthreads?

The alternative would be to reduce the request timeout to a reasonably low value so that it won't crash the entire website. So maybe change CURLOPT_TIMEOUT, or rather requestTimeout, to something like 3-5 seconds by default, and make this configurable in the plugin settings? I would prefer certain visists not to be tracked over certain visitors seeing an error page because matomo failed to respond in time.

NicoHood commented 2 years ago

I think this needs to be fixed upstream: https://github.com/matomo-org/matomo-php-tracker/issues/88

I am using the javascript tracking on my site now, which is also available with this plugin.

salixh5 commented 2 years ago

Grav does some magic here to provide an onShutdown event that the plugin could hook into. At least for systems that run PHP-FPM it should work fine I think, not sure about FastCGI (they do some crazy stuff like header('Content-Encoding: identity'); which just strikes me as odd because it explicitly should not be used but maybe it works).

Anyway what do you think? Even without any upstream fixes, shouldn't that already solve the problem? If you think so, I can try writing a PR.

NicoHood commented 2 years ago

That sounds nice, but does it work for you? Have you tested it?

salixh5 commented 2 years ago

Haven't tested implementing this here in this plugin, but I have used fastcgi_finish_request() previously in another project and it worked great for similar use-cases. Biggest downside being that the function is only available when using PHP-FPM. I haven't tested any of the workarounds for FastCGI that Grav is employing.

This technique would obviously be incompatible with JavaScript tracking and it wouldn't be possible to output a blocking reason to JavaScript file anymore. Other than that, I don't think the plugin would need a lot of modification so maybe I'll just make a fork and give it a try.