[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: openldap.git branch master updated. b7a291a488dff3902931559670cf94c7abe2655b

openldap-commit2devel@OpenLDAP.org wrote:

A ref change was pushed to the OpenLDAP (openldap.git) repository.
It will be available in the public mirror shortly.

The branch, master has been updated
        via  b7a291a488dff3902931559670cf94c7abe2655b (commit)
       from  1ab08d2f8e4c9baf71e3c146e95d013d7b8bd656 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit b7a291a488dff3902931559670cf94c7abe2655b
Author: Howard Chu <hyc@openldap.org>
Date:   Wed Jul 8 14:22:29 2015 +0100

     Experimental syslog() replacement

     2-3x faster than libc. Add it to the Makefile yourself if you want to test it.

-----------------------------------------------------------------------

Summary of changes:
  servers/slapd/overlays/syncprov.c |    3 +-


Oops. Ignore the above, reverted already.


  servers/slapd/syslog.c            |  329 +++++++++++++++++++++++++++++++++++++
The most obvious braindeadedness in glibc syslog() is that it acquires a mutex before writing to the log socket. This is utterly inane; the log socket is datagram-based and as such all writes to it are already atomic and need no mutex protection.
The other big problem is that the function that generates the log timestamp also acquires 2 mutexes. I avoid all that crap too by writing my own implementation of localtime(). This overhead can be reduced further still by simply omitting the timestamp - it turns out that modern syslogds (rsyslog, syslog-ng) actually ignore the timestamp in the message and generate their own anyway. (Note that this localtime implementation is broken wrt DST.)
There are a few other areas to explore here, including a log socket per thread, which would improve throughput even more in heavy workloads. These things can be explored without major overhauls of existing code.
For greater throughput we need a logging mechanism that doesn't rely on sprintf. I.e., we should consider a binary log format where we simply pass around short message IDs (and relevant message parameters) and use a compiled message catalog that maps IDs to text. This would require a post-processor to read the binary log and generate human-readable messages somewhere else. (It's obviously not a new concept, IBM mainframes have done this for decades; the Microsoft system logger does this as well.) 

--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/