[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: libsvn_repos logging -- design problems

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2005-07-15 18:02:28 CEST

On Fri, 2005-07-15 at 10:23 -0500, Ben Collins-Sussman wrote:
> The logging API can still do the loglevel-test, but server
> processes should cache the repository's loglevel and avoid
> constructing messages when they can. This can be documented as a
> 'best practice', or we can create a macro like branko demonstrated.

My advice is to ignore Branko's concern until it becomes an issue; when
it does, we can optimize performance in successive steps by (1) querying
the log level to avoid creating arguments, and (2) caching the log level
to avoid making any function calls.

But this brings up another point: your svn_repos_write_accesslog()
(which is much too long of a name for a commonly-called function,
incidentally) should take a variable argument list. Then, at least the
top-level apr_snprintf can be avoided whenever the log level is too low,
and there is no performance issue in the common case where the arguments
are readily available.

> * PROBLEM: logging errors or requests not associated with repositories.

I tentatively agree with your later conclusion that only access logs
should be per-repository, and that we should leave error logging to the

> * PROBLEM: lots of processes all trying to write to logfiles.

In Unix land, at least, if you open a file for append on a local
filesystem, write() is atomic. So generally logging wins because the
log messages fit within the buffer size and are written out with a
single write().

File locking could create performance issues and deadlock issues, and I
advise against going down that path.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 15 18:04:00 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.