No need for cache warm-up for the system to perform

[nightowl888]

No need for cache warm-up for the system to perform

[NightOwl888]

I saw that "no need for cache warm-up for the system to perform" is one of the main features of the original BoboBrowse (http://senseidb.github.io/bobo/). Testing BoboBrowse.Net this seems to be not true. This is probably due to the features that this porting does not implement such as CollectDocIdCache and Util.MemoryManager. Is that correct?

This is one possibility (and lack of MemoryManager is probably a contributor). It is also possible that Lucene.Net is not as efficient as Lucene, or it might have something to do with your configuration.

Unfortunately, with my limited experience with Java it is difficult for me to work out exactly how the MemoryManager functions. My guess is that it is some kind of out-of-process distributed cache, but the pattern used doesn't look similar to a cache pattern in .NET. Not to mention, .NET doesn't have a built-in distributed cache.

Can you do something about that?

Possibly. But let's first try to nail down what the bottleneck is. First of all, you should ensure you are following Lucene.Net best practices for warm-up (see the next question). If you are still seeing issues, it would help tremendously if you could build a sample project to demonstrate what configuration causes the issue to occur (and any configurations that cause it not to occur).

Have you any advice for me?

First of all, building the index is supposed to be done out of band of the normal search. The index is typically built 1 time and then searches executed several times (possibly hundreds of thousands). You probably already know this, but I mention it just in case.

The Lucene.Net IndexReader is meant to be run as a singleton instance. Strangely, although many people seem to echo this advice, there are few code examples that show how to do it. This is the best one I found:

http://www.i-avington.com/Posts/Post/building-a-blog-redux-setting-up-lucenenet-for-search-part-7

Here are some other posts about the topic:

http://stackoverflow.com/questions/4948569/structuremap-conditional-singleton-for-lucene-net-indexreader
http://stackoverflow.com/questions/3480974/proper-structuring-of-lucene-net-usage-in-an-asp-net-mvc-site
http://stackoverflow.com/questions/12271614/lucene-net-indexwriter-setmergedsegmentwarmer/12272886#12272886
http://stackoverflow.com/questions/14473427/singleton-pattern-for-indexwriter-and-indexsearcher-lucene-net
https://dzone.com/articles/how-add-search-capability-net

Do note that IndexReader implements IDisposable, so when the cache is expired, Dispose() must be called explicitly on the reader. In other words, a static method won't work for this, instead one of the .NET caching mechanisms should be used so an event can be used to properly dispose the instance, or alternatively many DI containers will do this properly.

It is unclear if BoboIndexReader is also supposed to be run as a singleton instance. According to @zhengchun, it must be, but I found no documentation (in English, anyway) to back up this claim. It does seem to make sense, though, because there is some overhead to loading index readers and there is a public PutRuntimeFacetHandler() method that can be used to add facet handlers dynamically (which wouldn't be needed if the BoboIndexReader were loaded on every request). There is also a public InnerReader property that can be used to access the underlying Lucene.Net IndexReader instance so you don't necessarily need to cache it separately.

Do note that BoboIndexReader also implements IDisposable, so it should also be disposed properly if used as a singleton.

There are also workflows that use both an IndexReader and an IndexWriter simultaneously that can be complex. If you are using something like that I recommend you do more research on how to configure Lucene.Net in that case and take it into consideration when you are using BoboBrowse.Net.