一旦我的应用程序爬升到> 1000个对象，太阳黑子Solr减速为野兽
我很好奇是否有人注意到Sunspot-Solr的任何缩放问题。 即使我删除了所有可搜索的参数，它本身只是反对原始类; 在我的本地加载还需要5到8秒，生产时需要4到5秒。
有没有其他人能够扩大太阳黑子 – 索尔？ 有哪些常见问题？
怎么能更深入地研究这个？
这是单个请求的Solr日志：
Solr Select (208.1ms) {:rows=>20, :start=>0, :q=>"*:*", :sort=>"score desc", :fq=>["type:Organization", "published_b:true", "updated_at_d:[2009\\-02\\-03T16\\:11\\:55Z TO *]"]} Solr Select (5.5ms) {:rows=>20, :start=>0, :q=>"*:*", :sort=>"score desc", :fq=>["type:Organization", "published_b:true", "updated_at_d:[2009\\-02\\-03T16\\:11\\:55Z TO *]"]} Solr Update (12.6ms) UserActiveRecord::BaseUser 2UserBob2009-09-28T21:00:27ZMarleybob.marley@gmail.comBob MarleyMarleyBobbob.marley@gmail.comBob Marley Solr Update (487.7ms) Completed in 12632ms (View: 11633, DB: 228) | 200 OK [http://localhost/organizations/search] 对于Solr来说，1000个对象是孩子们的游戏，所以这里有一些可疑的东西，大约200毫秒的Solr读取。 但是，您最直接的问题是您在看似GET请求期间写信给Solr – 这是怎么回事？ 您是否正在保存可搜索的对象，这会触发Sunspot的自动索引？ 如果您需要在GET请求过程中更新模型（如果可能，应该在后台作业中完成），您需要在太阳黑子中禁用自动索引：
searchable :auto_index => false # sunspot setup end
然后，当您确实想要在Solr中更新它们时，您需要在控制器中显式调用my_model.index 。
最后，最后的大更新是Solr提交，它告诉Solr将未分级的更改写入磁盘并加载反映这些更改的新搜索器。 提交费用昂贵; 默认情况下，Sunspot :: Rails在写入Solr的任何请求结束时执行提交，但此行为针对的是Sunspot的新用户而不是生产中的实时应用程序的最小惊喜原则。 您需要在config/sunspot.yml禁用它：
auto_commit_after_request: false
然后你可能想在solr/conf/solrconfig.xml配置autoCommit – 它在默认的Sunspot Solr发行版中被注释掉，并且那里也有一个解释。 我发现每分钟一次是个好地方。
在进行这些更改后，我会看到您的读取是否仍然很慢 – 我认为很可能原因是每次搜索时，您对Solr的写入/提交都会导致它必须加载新的来自磁盘的搜索者。 因此，它不能允许任何内部缓存加热等，并且通常会承受巨大的压力。
希望有所帮助！
当我在更新提交期间遇到长时间请求时，我偶然发现了这个博客
mytechmembank.blogspot.de
事实certificate我必须改变以下内容：
Performance killer: true Way to go: false
在solrconfig.xml中