ignite-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "steve.hostettler" <steve.hostett...@gmail.com>
Subject Re: LoadCache Performance decreases with the size of the cache
Date Mon, 26 Dec 2016 15:42:04 GMT

while investigating, I understood why I do have a lot of locks on Lucene
Documents in java mission control. That is because as soon as there is
String in the index, this is handled by Lucene even if you do not want full
text search (The string being a identifier).

--- From IgniteH2Indexing.java
            if (type().valueClass() == String.class) {
                try {
                    luceneIdx = new GridLuceneIndex(ctx, schema.offheap,
schema.spaceName, type);
                catch (IgniteCheckedException e1) {
                    throw new IgniteException(e1);

Altought I do understand why this has been done that way, I wonder whether
it would not be better to let the user choose it. Lucene brings a lot of
features but also has an impact on the performances. In my case, I know that
the index on the string will never ever been searched as a substring.

The Lucene Index management seems to heavily rely on locks and therefore the
more threads the more contention on the index.

Is this a known behavior? Am I missing something.
Furthermore, there seems to be a "rebuildIndexes" method.  I am not sure
what this method do but if it efefctively rebuilds the index then I could do
a measure without indexes (t1) and then a measure with indexes (t2). After
that I rebuild the indexes (t2). Hence, if t1 + t3 < t2 then it means that
disabling the indexes during load make sens from a performance perspective.
Am I correct?

View this message in context: http://apache-ignite-users.70518.x6.nabble.com/LoadCache-Performance-decreases-with-the-size-of-the-cache-tp9645p9738.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

View raw message