[
https://issues.apache.org/jira/browse/OAK-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13965416#comment-13965416
]
Jukka Zitting commented on OAK-1702:
------------------------------------
bq. Nobody disagrees with this, we just happened to notice some other stuff
along the way that's all.
The problem here is that until the key problem is addressed, correctly
interpreting the performance impact of smaller changes is very tricky.
For example, given Lucene's field cache, the compression overhead we're seeing
now because of repeated intializations of the IndexSearcher might simply vanish
once the key problem is addressed. And what's worse, if we disable the field
compression, we won't be able to fit as much of the index in local caches,
which may well end up hurting performance for larger deployments.
> Create a benchmark for Full text search
> ---------------------------------------
>
> Key: OAK-1702
> URL: https://issues.apache.org/jira/browse/OAK-1702
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: bench
> Reporter: Chetan Mehrotra
> Assignee: Chetan Mehrotra
> Fix For: 1.1
>
> Attachments: OAK-1702-hack.patch, OAK-1702-lazy-cursor.patch,
> OAK-1702-shared-indexer.patch, OAK-1702.oakcodec.patch, OAK-1702.patch
>
>
> To compare the performance of Full text search between Jackrabbit 2 and Oak a
> benchmark should be added.
> To start with the benchmark would do following
> * Would be based on WikipediaImport benchmark. So it would import the
> wikipedia dump and perform full text query on that
> * Should be able to run on both JR2 and Oak. Need to account for maven setup
> to handle different Lucene version as JR2 uses 3.6.0 and Oak use 4.x
> Later we can add concurrent version
--
This message was sent by Atlassian JIRA
(v6.2#6252)
