Ticket 616 - High contention on computed attribute lock
Bug Description:
On search request, some requested attributes are computed:
- subschemasubentry
- nscpentrywsi
- numsubordinates
- hassubordinates
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.
In short:
On standard deployment computed filters and computed attributes lists are unchanged
after startup.
Computed filters/attribute are only added to the lists.
Fix Description:
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)
https://fedorahosted.org/389/ticket/616
Reviewed by: Rich Megginson (thanks Rich !)
Platforms tested: 1*4cores fedora and 8*4cores RHEL6.4
Flag Day: no
Doc impact: no