Massive Amounts of /wp-admin/ Requests on Update

PHP 7.2.16
Apache/2.4.18 (Ubuntu)
plugin: 12.6.2 [up to date]

Hi there,
[please don’t read any resentment or ill-will into my post :D]

After a couple of weeks of frustration where our multisite that we use to develop new websites kept going “down” every once in a while – presumably taking down the entire web server with it – it seems like I have found the culprit. I might be wrong, but I think it is worth bringing this issue up, regardless.

A quick look at the code shows that whenever WP Statistics detects that the plugin has been updated, it runs a bunch of db queries to update the wp statistics tables. For multisites, it then runs a whole bunch of get requests to /wp-admin/ of all sub-domains with the intent that that would update their dbs as well.

The problem is that this does not seem to work:
GET /wp-admin/ HTTP/1.1″ 302 5
That looks like a redirect to wp-login.php to me.

It is worse than that, though. Unfortunately, I have lost the logs for some reason, so all I have for now is my memory and the new logs from today where nothing terrible happened.

Anyway, since there are a hundred blogs on this multisite, there are just as many requests to /wp-admin/, along with WP cron jobs right before each of them. Going by memory, every one of these requests (wp-admin/cron) took hundreds of seconds to complete (you can set Apache to log the request duration). I don’t know if they completed or if some program like monit restarted apache.

I hope there is a better solution for these db updates. ^^ One that works reliably and does not overload the server. Something like a request to wpstatistics/upgrade-db.php [no blocking] that then calls [sub-domain]/wpstatistics/update-db-this-subdomain.php or whatever for each sub-domain one by one.

Btw, I know that these requests came from this plugin, because I added backtrace code to the user agent of all requests triggered by WordPress/plugin code. The result was “class-wp-statistics-install.php” line 419.