Hello Dennis, On Thu, Dec 17, 2009 at 9:50 PM, Dennis van der Laan <[email protected]> wrote: > > Could this mean that there is not enough memory for the Lucene indexes > and the indexes are read from disk all the time?
The problem is not Lucene: if Lucene is slow, the problem is in *how* Lucene is used. > Any idea how large the indexes will become? I have no idea how the Depends on the size of your repository. We have sizes of around 20 Gb. Depending on what your queries are, you are fine > internals of Lucene look like. The virtual paths have an average string > length of about 50 characters and we end up having about 1 million of > these properties. Depending, again, on how you query this will lead to large memory consumptions. If you sort on it for example. Internally in Lucene a lot of memory is taken for it, and in Jackrabbit again. So, 50 chars, 4 byte a char (?) * 10^6 * 2 = 400 Mb... > > Thanks for any help! See next mail :-)) Regards Ard > > Dennis >> >>> A related question: could it be that when a query returns no results, >>> this is slower than when it does return a result? Might it have >>> something to do with Lucene not having an index for that particular >>> property value? >>> >> >> No, an inverted index structure does not suffer from this >> >> Regards Ard >> >> >>>> Hello Dennis, >>>> >>>> > >
