Details
-
Improvement
-
Status: Closed
-
Critical
-
Resolution: Invalid
-
None
-
None
-
None
Description
Ok, this will be an huge improvment, but also a huge modification. Here is the rational :
- each time we are searching for an entry using an attribute value, we are walking a B-Tree doing a comparizon between the given value and the stored value. if we have N values stored in the B-Tree, we will do something like Log2(N) comparizons.
- Now, we have to be aware that those comparisons must be done against the normalized value of the attribute, and using the assocaited MatchingRule. For instance, "Emmanuel", "EMMANUEL" and "emmanuel" are supposed to be the same value if there type is CommonName, so we must do an case insensitive comparison.
- a first optimization is already implemented : the incoming value is normalized before the search, so we avoid a systematic normalization of the incoming attribute
- but we will normalized each values which have been found into the server
- again, an optimization is implemented : a cache is used to store normalized values, so it happens that sometime, we just get the normalized value from the cache.
- but this cache has a limited size, and as it is a cache, each time we want to hit it, a synchronization occurs, which will lead to some concurrent access to slowdown.
At this point, the question is :
- why don't we store normalized values of attribute instead of simple values? The initial (not normalized) value is always present in the entry, so there is no need to keep it into the indexes.
This optimization could have a huge impact if it appears that, under heavy loads, the cache synchronization leads to delayed access.