Possible performance issue

Hello Daniel,

That is interesting. The plugin should send a single (uncached) request for every pageview the website receives, with most pageviews that should be disregarded (eg bots or visitors with Do Not Track enabled) already filtered out before that request is sent. It sounds like that somehow didn’t occur for your website, which I am going to look into.

That said, I also notice that you’re using our Boxzilla Stats plugin. Do the performance issues persist if you disable that plugin? It uses a far less optimized approach than Koko is, but it also depends on what percentage of visitors a Boxzilla box will show for.

Let us know please.

Hello Danny,

I took a look at the access log myself now, and here is the breakdown for the day in question:

– around 13.000 requests were made to: /koko-analytics-collect.php …
– around 7.000 requests were made to: /wp-content/plugins/koko-analytics/assets/dist/js/script.js?ver=1.0.24 HTTP/2.0

Koko Analytics shows around 8.500 visits and 13.000 page views for that day. Maybe that helps?

I’ve also deactivated Boxzilla and Boxzilla Stats for the moment and will report back. However, my first impression is that the CPU load hasn’t changed. We show a single box to mobile users, which is seen about 1.000 times per day.

Hello Daniel,

Thank you, that is really helpful! Those numbers look correct to me.

You had 13.000 pageviews and 13.000 requests to koko-analytics-collect.php, so that is perfect.

The tracking script (script.js) should be served from cache (if your website sets the proper cache headers, highly recommended on a busy website like yours) for visitors returning to your website. So while you had 13.000 pageviews, only 7.000 of those needed to fetch the script.js file from your servers. I’m not sure what # of site visitors Koko Analytics shows, but it is possible that this number should be way lower if you had fewer than 7.000 site visitors.

One note regarding cache headers is that you can safely set it to a super high value, at least a few days and probably way longer than that. WordPress includes a cache-busting version string by default so whenever a new plugin version is released, all browser caches are invalidated.

I just checked your cache headers and they seem to be set to 1 month, which is a fine value.

Now I’m not sure what else your server is doing but assuming those 13.000 requests to koko-analytics-collect.php happened in a 12-hour window (b/c sleep) equals about 1 request per 3 seconds. That is really not something that your server should be breaking a sweat over, given that it is a very simple request that loads the minimum amount of code necessary, writes a few bytes to a file and then exits immediately. Looking at your site, a request to that endpoint takes less than 40ms from request to response from where I am.

If you have command line access to your server, what does ps aux, top or possibly htop say about the top CPU% users?

• This reply was modified 3 years, 9 months ago by Danny van Kooten.

Thanks a lot Danny, it’s good to know that the plugin works as expected on my site. I agree with you that it should not be the culprit here. Unfortunately, I do not have command line access (and wouldn’t have the knowledge to do the stuff you recommended anyhow) – but I will ask my provider to give me some more insight into the CPU usage. Thanks again for taking your time to look into this!