We are building a system that uses SharePoint Auditing in a SharePoint Foundation deployment.
We are wondering about the degradation of performance overtime as the amount of audit information grows.
How often should we clear the auditing log, and how is this done?
We have auditing turned on for one of our web applications. Since it can generate a ton of data, we decided to create a separate database within the Sharepoint server. Two times a week, we selectively replicate the data to this other database. This cuts down on the number of items in the log. This allows us to report on the activity going on within the web application but not report on the viewing of CSS and other junk files like Muhimbi mentions.
We can then truncate the audit log without any fear of performance or space issues since the content resides elsewhere. It doesn't really answer any parts of your question, it's more of an anecdotal example of a real world use of auditing.
As one of the developers behind a popular SharePoint Auditing solution, let me share my 2 cents.
Auditing in SharePoint is (deeply) flawed and you are right to be concerned about performance, specifically:
Audit logs grow out of control as too much information is logged by default in certain areas, (and too little in other areas). For example requests to .master, .css, .js files and other rubbish you are most likely not interested in.
Audit Log files are not truncated automatically and if you want to do it from code it is usually an 'all or nothing' affair. We have seen customers with 100M lines of audit data in a matter of weeks.
Because the size of the log data grow out of control it becomes problematic to backup the content databases as that is where all this data is stored.
Because the size of the log data grows out of control, it become very difficult to query the logs using SharePoint's own UI, but then you are using SharePoint-Foundation, which provides no UI out of the box.
Some aspects of Auditing, including the various flaws, have been discussed before on this site, have a look at the following questions.
The product I have worked on solves the majority of these problems, so you may want to evaluate that. Obviously I am biased so the usual disclaimers apply.
Audting is one of those things that a lot of people just turn on without thinking about how much data can accumulate in a very short amount of time. When I was doing the BLOB remoting thing we would find customers whose audit data was nearly the size of their BLOB data and in some cases more.
So it's one of those features that IMO you should not turn on unless you absolutely need it and only then turn on the events you really want to audit...i.e. have a really good business value reason for turning on "View". Do you need check-in and check-out if you have edit?
As far as controlling audit retention, go to Site Actions > Site Settings > Site collection audit settings (under Site Collection Administration). I personally wouldn't keep more than 30 days.
