Based on user requests we’d like to add country information to download statistics on our system.
One thing we noticed, is that adding the GeoIP data to the usageStats processing, increases the size of the metrics table tremendously. The regional data adds quite a bit of granularity to the metrics: what previously was only a single row per day for a downloadable object, can now lead to several rows in the table as they are differentiated not only by country, but also by city. At worst each and every download might create its own row in the metrics table.
According to https://docs.pkp.sfu.ca/admin-guide/3.3/en/statistics#configure-regional-data-tracking there’s no way(?) around the processing of city information.
Our live system hosts ~30 journals of varying publication activity. For our use case, we’d need to reprocess usageStats starting with 01.01.2023. We started processing the logs with regional data since May 2025, and already noticed quite an uptick in the size of the table. Before fully committing to adding regional data to our system, we are wondering how OJS will perform when running reports on a metrics table having several million rows (growing each year by a substantial amount)?
Our question is to the users of multi-journal installations:
Do you use regional data for usage stats?
How is system performance when creating reports using this data?
Did you experience any odd side effects in everyday performance or during updating that could be traced back to the size of the metrics table?