--On Thursday, July 4, 2024 8:00 AM +0000 "Windl, Ulrich" u.windl@ukr.de wrote:
For case 1 that would mean "the database never grows" if the attributes changed are the same size as before, while For case 2 it means that either (2a) new values are written at some free space where old attributes once were (recycling free space), or (2b) the database has to grow at some point, allocating new "slack space" (what will become of "unsused old space" then?)
It was modifications of data, with different size attribute values. It was not case #1. Since it was not adding new entries or new attributes + values, it is more along the line of case #2. But again, the same changes were made with both back-mdb AND back-hdb. Even if you were to be *adding* new entries or attribute-value pairs, back-mdb requires less resources than back-hdb, that's already covered via the database size differences with slapadd.
So you measured the speed of the local accesslog database, and NOT the remote database (and the local accesslog writing will never be blocked by remote replication)?
replication is a read OP, so no it doesn't block the accesslog being updated on the provider. The point was measuring performance when 2x write ops were being made for every change.
In any case, the point is, again, back-mdb requires substantially fewer resources than back-hdb, and it is more performant than back-hdb in every scenario.
--Quanah