[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[EP-tech] Re: RFC access log table
Certainly it is an unwieldy beast (ours on 3.3.10 is xxx for approx 23 million records) but isn't that where IRStats gets its data?
As I understand it (and I may well have the wrong end of the stick) it will essentially collate the data out of access into its own summary tables, but I don't know if clearing access will mess up the historic stats once they have been collated?
I think it is generally a good idea to reduce the table size (it will keep the db admin happier!) but I think it would need to be optional (eg some kind of cron job), and we/you may need to look at what amendments might be needed to ensure IRstats & any homebrew stats plugins are cumulative and/or can review the csv log files to rebuild the necessary stats, either if initially setup or during some recovery, eg if the hardware breaks.
Might be nice to have a config for how long the data should stay in the access table - eg keep last 6/12/24 months in the db.
More options are (usually) better.
From: Tim Brody [mailto:tdb2 at ecs.soton.ac.uk]
Sent: 14 February 2013 10:01
To: eprints-tech at ecs.soton.ac.uk
Subject: [EP-tech] RFC access log table
I'm thinking about the access log table and how it can be made sustainable.
What I'm suggesting is to write accesses to CSV-formatted log files, one file per month. What I don't know is whether anyone is relying on the database table for generating statistics?
The problem the access log table creates is in backing-up the EPrints database.
I'd appreciate any thoughts/comments.
All the best,
The Open University is incorporated by Royal Charter (RC 000391), an exempt charity in England & Wales and a charity registered in Scotland (SC 038302).