-
-
Notifications
You must be signed in to change notification settings - Fork 123
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reading from file taking too long time inside container #260
Comments
Lucene does not work very well over network shares. This is a limitation of lucene and something that can't just be 'fixed'. You could use change the directory to be a lucene in memory index only but it means it will not be persisted. |
@Shazwazza is there any way to store the index inside the database or Redis cache? So that instead of reading from storage, we can read it from cache memory? |
Our scenario is, We have a process that will run once a day to build the index. After the index is ready, it will be stored in a shared folder and another API will read it to serve the user request. This is a very simple approach and it should be served without any limitations by lucene. |
A few things of things of note. Default DirectoryThe default directory is dependent upon OS. That is, if you call "Sharing" an IndexSince Lucene's built-in directories are optimized to work with a local disk, the way you share an index between multiple applications is to use Lucene.Net.Replicator. I don't know much about Examine, but I see that there is a reference to
Basically, it allows you to publish an index to a central location, and individual replication clients handle copying the index to each local disk for optimal performance. Custom DirectoriesThe |
We deployed our index inside docker container, .net core 3.1
Host os is debian
We placed the index file in a shared mounted directory.
The problem is accessing the index files taking huge time(60 seconds) for each request. We checked,.index size is only a few MB in size with around 200K small documents.
Interestingly the same thing takes 120ms in development environment running on windows os. Am i missing something? @Shazwazza
The text was updated successfully, but these errors were encountered: