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

libsvn_repos logging -- design problems

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2005-07-15 17:23:24 CEST

* PROBLEM: performance issues

According to branko, numerous debug-level apr_psprintf's add up fast
and hurt performance. It's bad to create these messages when
debug-level logging isn't even turned on.

Possible Solutions?

    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.

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

Sometimes errors happen before a repository is opened, or requests
come in on bogus URLs. This is still interesting stuff to log.
Where/how should it be done?

Possible Solutions?

     mod_dav_svn is already logging these sorts of things in apache's
     own logs. But svnserve is still out in the cold. Perhaps
     svnserve can have private code to write such things to logs in
     /etc/subversion? Or should this be shared code as well, making
     mod_dav_svn use it too? How do we make a clean conceptual
     distinction between per-repository logfiles and 'global' ones?

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

How do we mediate write access to a single logfile with N processes
all trying to write to it at once?

Possible Solutions?

      flock() style stuff, like the 'write lock' in FSFS?

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 15 17:24: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.