On Jan 3, 2023, at 5:17 AM, Quanah Gibson-Mount quanah@fast-mail.org wrote:
--On Friday, December 30, 2022 11:35 PM +0000 Christopher Paul chris.paul@rexconsulting.net wrote:
Using the oldie but goodie LDAP performance testing tool, SLAMD, I've been doing performance tests. What I found was that stats logging (olcLogLevel: 256) degrades performance significantly. A pity, because it is recommended in the manual. Also, it considered very useful by those of us who've been running OpenLDAP for a while.
Yes, this is a well known, documented, and discussed issue. It makes logical sense if you think of the massive overhead incurred with logging lots of information vs logging nothing at all. I would note that the amount of perf hit taken depends on the system setup. For example, if systemd is doing logging along with syslog, which is often the case these days, then that's your worst case scenario, followed by just direct logging to syslog being the next worst.
You might want to play with OpenLDAP 2.6 which allows direct logging to a logfile on disk, completely bypassing systemd and/or syslog, this is your best case scenario currently for when logging is necessary.
It gets worse on RHEL systems due to rate limiting, where large swaths of statements are skipped entirely.
I concur with Quanah. Use the 2.6 logger. My tests w/ a log level of sync (which includes stats), showed a perf boost of approximately a factor or 2.
I suppose one could achieve the same on earlier releases by disabling syslog and enabling the debug logger instead?
— Shawn