https://bugs.openldap.org/show_bug.cgi?id=10293
--- Comment #8 from Ondřej Kuzník <on...@mistotebe.net> --- On Tue, Aug 19, 2025 at 05:46:07PM +0000, openldap-...@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_modify > > and 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. -- You are receiving this mail because: You are on the CC list for the issue.
