以下SolrServer的实现之间有什么区别:
ConcurrentUpdateSolrServer HttpSolrServer CommonsHttpSolrServer(注意:现在不建议使用吗？)如documentation中所述:
ConcurrentUpdateSolrServer的文档建议将其用于更新，将HttpSolrServer用于查询。为什么是这样？
目前，我对所有内容都使用
HttpSolrServer，是否将ConcurrentUpdateSolrServer用于更新会带来显着的性能改进？ 最佳答案
我们目前在2017年，Solr社区将SolrServer重命名为SolrClient，目前我们有4种实现:
CloudSolrClient ConcurrentUpdateSolrClient HttpSolrClient LBHttpSolrClient 文档建议使用
ConcurrentUpdateSolrClient，因为它会将所有更新请求都缓冲到final BlockingQueue<Update> queue;中，所以更新操作的时间将比使用HttpSolrClient少，后者的行为是这样的-一旦收到更新请求，便立即将其触发。当然，我们信任该文档，但是获得此答案非常容易，这就是为什么我进行了一些性能测试的原因。但是，首先，我将描述客户端的不同操作。如果使用的是SolrClient的
add操作，则创建HttpSolrClient或ConcurrentUpdateSolrClient不会有任何区别，因为这两种方法都将执行相同的操作。 ConcurrentUpdateSolrClient仅在您明确地执行UpdateRequest时发光索引维基百科标题(code)的测试结果:
我的机器是:Intel i5-4670S 3.1 Ghz 16 Gb RAM
ConcurrentUpdateSolrClient (5 threads, 1000 queue size) - 200 seconds
ConcurrentUpdateSolrClient (5 threads, 10000 queue size) - 150 seconds
ConcurrentUpdateSolrClient (10 threads, 1000 queue size) - 100 seconds
ConcurrentUpdateSolrClient (10 threads, 10000 queue size) - 30 seconds
HttpSolrClient (no bulk) - 7000 seconds
HttpSolrClient (bulk 1000 docs) - 150 seconds
HttpSolrClient (bulk 10000 docs) - 80 seconds
概括:
client.add(doc);比ConcurrentUpdateSolrClient的执行速度至少快10-20倍，这是因为使用了ThreadPool和Queue(又名Bulk操作)HttpSolrClient，您仍然可以通过手动创建多个客户端，运行其他线程并使用一些中间存储(例如List)来模仿此行为。它肯定会提高性能，但需要其他代码。