modify performance is highly impacted by the backend lock and entry cache lock contention.
A couple of tickets are related to this and suggest changes to improve performance, but

• it is not guranteed that each optimization id good for all deployments
• it is a sensitive area and there is a possibility of unexpected side effects

To move forward I suggest to implement some backend related optimizations, but allow to turn them on or off, so it is possible to keep the current behaviour and deploy the optimizations after testing in a specific deployment.

For the beginning, I think the following optimizations should be considered:

• do not update the database ruv in the modify transaction, let it be done by the calls to _replica_update_state in the event loop. This is handled specifically by#564, but it is not finally commited and some environments may want to keep the ruv update in the modify txn

• reverse order of txn_begin/commit and backend_lock/unlock:

with the fix for #568 it is save to use batching of transaction log flush, but if the transaction is nested inside the backend lock, always only one transaction will be active, so the effect is not visible

• move code out of the backend lock:

in a modify operation there is a lot of initial work done after taking the backend lock, but not everything requires this protection as no database access is involved, eg
-- check for illegal mods
-- check access to the entry
-- make copies of the mods to restore in a retry
-- make copies of the entry for use in plugins
some of the above depend on the enty already be found and locked in the entry cache (the entrycache itself is addressed in performance tickets #414,#614).
There is no obvious reason that the find_entry2modify cannot be done before taking the backend lock, but this would request thorough investigation and testing. For testing it could help to have a switch to turn this behaviour on