Hi Guys,

I have a big problem on my application: the first search after I start the glassfish is slow, as I have already learned, because the IndexReader is 'warming-up'. The searches after that are very fast.

Ok, so far, so good. So, what's the problem?

I learned as well, that if you open a new IndexReader it has to warm up too, so the first search will be slow again. And that a new IndexReader is open after a change in the Index.

So there's where my problem is, the enviroment here has a HUGE ammount of documents to index. And the use of the application creates more and more documents to index. So, there is always a change in the index and there's always a new IndexReader.

Other thing that I found out testing is that if I disable the sorting (I sort for 3 fields when seaching) the search is always fast (except the first one), I couldn't find out why yet. But the sort is very important and I can't disable it.

Any ideas, suggestions or explanation if I said something wrong?

Thanks, any help will be immensely appreciated.

Hi,
did you verify if the searches are slow? do you have some numbers?
The default ReaderProvider does NOT open an indexreader after each change, it is able to refresh the existing IndexReader and is going to share most of the internally warmed up buffers.
http://docs.jboss.org/hibernate/stable/search/reference/en-US/html_single/#d0e624

Of course the first query when starting the application will still be slow.


Yes sorting is more expensive and needs more memory than not sorting. You should profile the application and see if tuning the memory settings of the JVM could help. Other than that, yes search engines need good hardware, especially memory: give enough memory to the JVM to let it sort efficiently but not too much as it will make GC more expensive, and especially you want to allow the OS to buffer as much as possible from your disk (so the OS needs memory too).

Ok, some numbers:

The search code:




With the sort:
The 1º search took 19281ms
2º: 99ms
3º: 58ms
4º: 22ms
5º: 19ms
then I indexed one document....
6º: 21360ms
7º: 21ms


Without the sort:
First search took 315ms
2º: 46
3º: 35
then I indexed one document...
4º: 34


As you can see, the sort is messing everything up... Maybe when I sort it has to open all the buffers again? I don't know...

Sort code:

Thanks for sharing those numbers; interesting I've never seen such a slowdown from a single insertion.



That's an outrageous slowdown, not acceptable, I agree.

Two points to check:

1 - Do you have enough free memory? Could you log GC activity too, just to make sure it's not messing with the numbers.
I agree it seems unlikely but still if you're working close to the memory limits it will need to open a new segment, and free another.. GC might need to kick in with an expensive "stop the world" collection, if the extra segment in memory is too much to handle.

2 - Could you try upgrading Lucene from 3.1 to 3.3 ? Just to make sure we're not hitting an already fixed regression. It seems strange that this kicks in only when sorting.

Good news is that Hibernate Search 4 is introducing a NearRealTime mode, in which the IndexWriter doesn't need to flush after each commit and the readers can search also in the unflushed buffers from the writer.

Hi again, thanks for your help

I use lucene 2.4.1, maybe that can be the problem?

Yes, definitely.
And which version of Hibernate Search then?
I'd recommend to use 3.4.1.Final with Lucene 3.1.0 as this is the latest stable combination. If it still doesn't help, then you should try Lucene 3.3.0

I use Hibernate Search-3.1.1.GA

I see. Could you please upgrade and then let me know your new numbers?

I'm trying to do that, but I'm facing some incompatibility problems like RangeFilter and RangeQuery doesn't exist anymore in Lucene and StandardAnalyzer is final now and I can't extend it.


In fact I think I already figured out the former problem (they renamed to TermRangeFilter and TermRangeQuery) but the latter I am still trying to resolve..

It worked!

New numbers below


With the sort:
The 1º search took 999ms
2º: 47
3º: 31ms
then I indexed one document
4º: 32ms
5º: 31ms


Thanks a lot!

great, thank you for sharing some numbers.
Good to see that even the first query was much faster.