jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Parvulescu <alex.parvule...@gmail.com>
Subject Re: Slow full text query performance and Lucene Index handling in Oak
Date Wed, 09 Apr 2014 13:20:16 GMT
Profiling the result shows that quite a bit of time goes in
org.apache.lucene.codecs.compressing.LZ4.decompress() (40%). This I
think is part of Lucene 4.x and not present in 3.x. Any idea if I can
disable compression?

+1 I noticed that too, we should try to disable compression and compare
results.

alex


On Wed, Apr 9, 2014 at 3:16 PM, Chetan Mehrotra
<chetan.mehrotra@gmail.com>wrote:

> On Wed, Apr 9, 2014 at 5:14 PM, Jukka Zitting <jukka.zitting@gmail.com>
> wrote:
> > Is that a common use case? To better simulate a normal usage scenario
> > I'd make the benchmark fetch up to N results (where N is configurable,
> > with default something like 20) and access the path and the title
> > property of the matching nodes.
>
> I changed the logic of benchmark in http://svn.apache.org/r1585962.
> With that JR2 slows down a bit
>
> # FullTextSearchTest               C     min     10%     50%     90%
>   max       N
> Oak-Tar                            1      34      35      36      39
>    60    1639
> Jackrabbit                         1       5       5       6       7
>    68   10038
>
> Profiling the result shows that quite a bit of time goes in
> org.apache.lucene.codecs.compressing.LZ4.decompress() (40%). This I
> think is part of Lucene 4.x and not present in 3.x. Any idea if I can
> disable compression?
>
> Chetan Mehrotra
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message