我无法理解Lucene的复杂性。任何帮助将不胜感激。
我们使用Windows Azure blob来存储我们的Lucene索引，包括Lucene.Net和AzureDirectory。 WorkerRole包含唯一的IndexWriter，每天添加20,000或更多记录，并更改现有文档的少量（少于100个）。设置另一个框上的WebRole以获取索引的两个快照（到另一个Azure目录中），在两者之间交替，并告诉WebService在可用时使用哪个目录。
WebService有两个IndexSearchers交替，在下一个快照准备就绪时重新加载 - 一个IndexSearcher应该一次处理所有客户端请求（直到新的快照准备好）。 IndexSearcher有时需要很长时间（分钟）才能实例化，有时则需要很长时间（几秒钟）。由于目录在物理上已在磁盘上（在此阶段不使用blob），我们预计它将是一个快速操作，因此这是一个令人困惑的问题。
我们目前的记录大约有800万条。 Lucene搜索曾经如此之快（很棒），但现在它很慢。为了尝试改进这一点，我们已经开始使用IndexWriter.Optimize索引每天一次备份 - 一些在线资源表明经常更改索引不需要Optimize，但其他资源表明需要优化，所以我们不确定。
最大的问题是，只要我们的网站拥有的流量超过单个用户，我们就会在Lucene搜索上获得超时。我们试图弄清楚IndexSearcher对象是否存在瓶颈。它应该是线程安全的，但似乎有些东西阻止了请求，因此一次只执行一次搜索。该框是Azure VM，设置为中等大小，因此它有大量可用资源。
感谢您提供的任何见解。显然，如果您有任何进一步的问题，我可以提供更多细节，但我认为这是一个良好的开端。
答案 0 :(得分：0)
我有更大的索引，并没有遇到这些问题（约1亿条记录）。
IndexSearcher是线程安全的，应该被重用，但我不确定这是不是现实。在Lucene 3.5（Java版本）中，他们有一个SearcherManager类，可以为您管理多个线程。 http://java.dzone.com/news/lucenes-searchermanager
同样是非Lucene帖子，如果您使用超大型虚拟机，请确保您正在利用所有核心。特别是如果你有一个Web API / ASP.NET前端，那些调用都应该是异步的。