Lucene搜索緩慢通過AzureDirectory

Question

我無法理解Lucene的複雜性。任何幫助，將不勝感激。

我們使用Windows Azure blob來存儲Lucene.Net和AzureDirectory的Lucene索引。 WorkerRole包含唯一的IndexWriter，每天添加20,000條或更多條記錄，並更改少量（少於100條）現有文檔。另一個框上的WebRole被設置爲將索引的兩個快照（進入另一個AzureDirectory），在兩者之間交替，並告訴WebService在可用時使用哪個目錄。

WebService有兩個IndexSearcher交替重新加載，因爲下一個快照已準備就緒 - 一個IndexSearcher應該一次處理所有客戶端請求（直到更新的快照已準備就緒）。 IndexSearcher有時需要很長時間（分鐘）才能實例化，而其他時間則非常快（幾秒鐘）。由於該目錄已經在磁盤上物理存在（不在此階段使用blob），因此我們預計它是一個快速操作，所以這是一個令人困惑的地方。

我們目前有約800萬條記錄。 Lucene搜索過去很快（很棒），但現在速度很慢。爲了改善這一點，我們開始使用IndexWriter。在我們備份後每天優化一次索引 - 一些在線資源表示Optimize對經常變化的索引不是必需的，但是其他資源表明需要優化，所以我們不確定。

最大的問題是，無論何時我們的網站比單個用戶擁有更多流量，我們都會在Lucene搜索中獲取超時。我們試圖找出IndexSearcher對象是否存在瓶頸。它應該是線程安全的，但似乎有些東西阻止了請求，因此一次只能執行一次搜索。該框是一個Azure虛擬機，設置爲中等大小，因此具有大量可用資源。

感謝您提供的任何見解。顯然，如果您還有其他問題，我可以提供更多的細節，但我認爲這是一個好的開始。

Answer 1

我有更大的索引，並沒有遇到這些問題（約1億條記錄）。

• 把指標在內存中，如果你能（800萬個記錄聽起來像它應該裝入內存取決於分析領域等的量），您可以使用RamDirectory作爲緩存目錄

• IndexSearcher的是線程安全並且應該被重新使用，但我不確定這是否是現實。在Lucene 3.5（Java版本）中，它們有一個SearcherManager類，可以爲你管理多個線程。 http://java.dzone.com/news/lucenes-searchermanager

• 另外一個非Lucene的帖子，如果你在一個超大型的+ VM上，確保你利用了所有的核心。特別是如果你有一個Web API/ASP.NET前端，那麼這些調用應該是異步的。