You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi,
I'm a first time user of the piwik-php-tracker and I'm wondering how to integrate tracking in our project. I like to use it to trigger some events in the backend and send those to piwik so they can be viewed nicely in the piwik-UI. But I don't want to block the backend code with those calls. What if the piwik server does not answer? The default request-timeout is set to 600secs with a nice comment (https://github.com/piwik/piwik-php-tracker/blob/84a994a4d34a601a1b1da2c44a122807a1c4ad5b/PiwikTracker.php#L146). Maybe I'm wrong, but its sounds like a dangerous default. One can set the curl-timeout with ->setRequestTimeout() to a minimum of 1sec. But thats still a lot of time.
My question: is the piwik-php-tracker the right choice to track events out a complex webapp context? I could imagine to use pthreads (http://php.net/manual/de/book.pthreads.php) or overwriting the ->sendRequest() method to use CURLOPT_TIMEOUT_MS instead of CURLOPT_TIMEOUT to minimize the blocking. I'm not interested in the piwik-response atm.
How do you handle this in your projects?
The text was updated successfully, but these errors were encountered:
nonsenz
pushed a commit
to nonsenz/piwik-php-tracker
that referenced
this issue
Jan 19, 2015
After some more testing I'm not sure how to handle this because curl behaves not the way I want it to. On some systems CURLOPT_NOSIGNAL => 1 is needed to get the _MS stuff to work. More info about the can be found here. To have really short timeouts, the CURLOPT_TIMEOUT should be changed to CURLOPT_CONNECTTIMEOUT, because we still want to get the request send to piwik. I still have problems with timeouts < 100ms and I don't understand why.
ATM I think it's better to track actions in the frontend only. I could write data from the backend in the DOM and process it with some js-code in the frontend.
After all I would like to hear how you handle this in your projects.
@nonsenz you can customise the requestTimeout attribute and set it to 1 second. If that's not good enough, then don't use the doTrack* methods (which will use CURL or Fopen streams), and instead fetch the URL with calling getUrl* method and call yourself using your favorite flavor).
There's also the possibility to bulk requests using enableBulkTracking() which can sometimes be useful
Enables the bulk request feature. When used, each tracking action is stored until the doBulkTrack method is called. This method will send all tracking data at once.
Hi,
I'm a first time user of the piwik-php-tracker and I'm wondering how to integrate tracking in our project. I like to use it to trigger some events in the backend and send those to piwik so they can be viewed nicely in the piwik-UI. But I don't want to block the backend code with those calls. What if the piwik server does not answer? The default request-timeout is set to 600secs with a nice comment (https://github.com/piwik/piwik-php-tracker/blob/84a994a4d34a601a1b1da2c44a122807a1c4ad5b/PiwikTracker.php#L146). Maybe I'm wrong, but its sounds like a dangerous default. One can set the curl-timeout with ->setRequestTimeout() to a minimum of 1sec. But thats still a lot of time.
My question: is the piwik-php-tracker the right choice to track events out a complex webapp context? I could imagine to use pthreads (http://php.net/manual/de/book.pthreads.php) or overwriting the ->sendRequest() method to use CURLOPT_TIMEOUT_MS instead of CURLOPT_TIMEOUT to minimize the blocking. I'm not interested in the piwik-response atm.
How do you handle this in your projects?
The text was updated successfully, but these errors were encountered: