https://bugs.openldap.org/show_bug.cgi?id=10293
--- Comment #8 from Ondřej Kuzník ondra@mistotebe.net --- On Tue, Aug 19, 2025 at 05:46:07PM +0000, openldap-its@openldap.org wrote:
To remind others: in the sylog project and the ollrpt project on our gitlab instance I looked for lines whose bodies began with:
syncrepl_message_to_op: rid=002 be_modifyand created a pseudo-request. In `ollrpt` I added artificial "tag" values. I created a record in my temporary file(s) were used and included these pseudo-request counts in the summary report.
Except this type of log message was never intended to be meaningful for performance/result tracking etc. Even if it was, there is a fair amount of processing that has no equivalent to these that you would lose out on.
`ollrpt` is the better of the two for this. I asked @nivanova to produce, in the STATS log a record with RID, tag, etime, etc. which she did and I reviewed the output.
And they pretended that anything that reached out to the overlay stack was a request, most egregiously the *internal* searches/questions which was beyond unacceptable. Quanah closed the MR before I managed to on these grounds, so I outlined that in a previous comment here.
These are not requests, they are internal work items whose timings have no relation to what is actually happening. Again, if we did *this* you'd either miss a large proportion of actual time or be double-counting making the "stats" completely bogus.
Take a configuration with a unique overlay, autogroup and ppolicy for an analogy. By the logic you proposed their own (interleaving!) "sub-requests" should also be reported and counted? How would this work if you still have the final result and its etime on top of it?
It would simplify log reduction and feed a reporting tool we use extensively to judge system activity. Similar reports have been done with mtail as I remember, gathering these pseudo-requests and their etimes and merging them internally (as COULD be done in `ollrpt`. The original ask was to merge @nivanova's work at least in a test build to evaluate and consider shipping as an improvement in STATS level reporting.
I am well aware that syncrepl is complex and much of what has been mentioned implies I was asking for much more which I was not.
Please engage with the suggestions (two) I outlined in my comment from yesterday which deals with all of the above *and* would actually simplify your "log reduction". To repeat, there are no actual MODIFY/DELETE/RENAME requests received from the provider, we get a message that we interpret based on the contents of our own DB, resulting in 0 or more probes and actions and the proposals account for this giving you the "real" cost as well.