Ticket 616 - High contention on computed attribute lock
On search request, some requested attributes are computed:
This is done with a linked list of registered callback.
When sending the results, each requested attribute is evaluated against all the callbacks.
When going through the callbacks list the thread hold the lock on the list.
Currently all the server callbacks are registered at startup time with only
one thread registering them (main).
A custom plugin may register custom callback using slapi_compute_add_evaluator
The important point is that callback are only added to the list.
Also on standard deployment without custom plugin adding new computed attribute,
this list is built at startup.
The problem on computed attribute is that it can create contention between search threads
trying to evaluate/compute the requested attributes
The same description applies to computed filters. For example with 'views' or
filters containing "subordinates", the filter is recomputed.
This using a linked list of callbacks registered during startup.
A custom plugin may register custom callback using slapi_compute_add_search_rewriter.
On standard deployment computed filters and computed attributes lists are unchanged
Computed filters/attribute are only added to the lists.
The fix consist to not protect the access to computed filter/attribute unless a
computed filter/attribute is added after startup.
The fix also contains a improvement of rsearch to support filters larger than 256 char
The fix also contains reworks according to review feedback.
Basically using a temporary variable to hold the actual value of require_*
The benefit is limited to 2% in terms of search throughput (8*4core machine)
Reviewed by: Rich Megginson (thanks Rich !)
Platforms tested: 1*4cores fedora and 8*4cores RHEL6.4
Flag Day: no
Doc impact: no