EPrints Technical Mailing List Archive

Message: #01570

< Previous (by date) | Next (by date) > | < Previous (in thread) | Next (in thread) > | Messages - Most Recent First | Threads - Most Recent First

[EP-tech] Re: RFC access log table

Hi Tim,

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.

Alan.

-----Original Message-----
From: Tim Brody [mailto:tdb2@ecs.soton.ac.uk] 
Sent: 14 February 2013 10:01
To: eprints-tech@ecs.soton.ac.uk
Subject: [EP-tech] RFC access log table

Hi All,

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,
Tim

-- 
The Open University is incorporated by Royal Charter (RC 000391), an exempt charity in England & Wales and a charity registered in Scotland (SC 038302).