Solr性能优化之QTime的误区

榕叶

　　最近公司的其中的一个集群的solr出现了一个比较奇怪的事情，先简单说说以下的情况
　　机器A是前端的逻辑应用
　　机器B是具体一个 solr 应用
　　很通用的方式都是从机器A向机器B的 solr 拿搜索结果并呈现给前端，机器A与机器B处于千兆局域网络。
　　前端的同事反应有时候, solr 返回的 QTime 很快，但实现搜索出来的结果时间却很久，我大概画了一个图，让大家更明白。

　　如上图所示，前端的同事在请求 solr 的方法前后加了时间计算，就是请求的所有时间，再前去 solr 反回的 QTime ，则就是网络的响应时间了。前端的同事发现，有些情况下，当然不是特定的条件，QTime 返回一般只就 100 ms 到 200 ms ，但网络的响应时间却比QTime 大很多，经常是１秒甚至更长。
　　找寻问题的根源：
　　１.　 基于这一个情况，当时我认为是内部的网络有问题，但通过机器之前的同步文件，速度也非常快，似乎都不存在过多的网络延时。
　　２.　因为 solr  那端是用了 tomcat ,当时有想过是否 tomcat 的连接池原因？通过更改 server.xml 的参数，问题似乎依然，但如果直通访问 tomcat 上的网页速度非常快，也看不出什么任何延时。
　　３.　会不会是 linux 主机的 sokcet 连接数，参数等影响了？因为机器安装上去后，我是看到并没有对 /etc/syscotl.conf 的参数做调整过，机器A与机器B也调整过了，但问题依旧。
　　４.　因为前端的机器A是用了 httpclient 的，把 httpclient 的连接池，参数等也调整过，问题依旧，最后把 httpclient 完全去掉了，改用了普通的 socket ,效果有一点点的改善，但不明显。
　　最后似乎都是无计可施了。。。。，按字面的理解，QTime 就是搜索的总用时。
　　在查看代码的情况下，在各搜索模块的 component 的 prepare , process 的时间都非常快，与QTime 很符合，当时我认为，搜索的过程就这样子了，时间很快哦，难道是把搜索的结果写回机器A时很久了？
　　最后在自己最不认为是问题的代码块中添加了一个时间检查，如下：

　　就从表面上来说，这段代码是所有的搜索操作都完成后，需要把搜索的结果 solrRsp 写到网络并回传到机器A的前端去，但这个时间耗用的时间与响应时间非常吻合，看来时间就是耗用在这个了，而且一个偶尔的发现，如果把solr 参数 rows=0 的时候，发现所有的响应时间非常短，都在几毫秒完成了。但就算 rows=1 也好，响应时间都有几十毫秒，这里我突然间意识到，在里面，肯定还有读写硬盘的操作并非仅仅是把结果写回网络中。
　　最后深入看代码后，发现了，其实 solrRsp 只拿到 docId, 具体的文档的内容，还需要通过 docId 从硬盘中读回来。正正就是这段时间损耗了，因为 QTime 在这之前已经结束了，并没有算上这一部分时间，导致了误解了 QTime 的与网络响应时间之前的关系。以　BinaryResponseWriter　为例子，时间都用在以下的代码里面的

　　因为群集中的索引比较大，一份索引约２０G左右，这机器总有４份，约８０G左右这时读取索引的内容反而成了瓶颈了。
　　　解决的方案：
　　一个能缓解这种情况的方法就是在 solrconfig.xml 中，把 docsCache 加大到１００W甚至更大，这个只能对于之前读取过的 doc 才能有效，所以这种方式只能是暂时缓解没有根本解决。
　　一个比较彻底解决的是，在启动的过程，通过 index.termEnum 把索引的所有相关的内容都采用延时加载到一个 数组中，一个 2000W ，只要内存有１６G以上那并不是什么难题。对于这么大的的数据量，肯定是只有一份索引在添加新的索引，其他的索引保持不变，就算有删除了数据，也不会 optimize ，所以这种方式还是能根本上解决以上的问题。
　　欢迎转载，请注册出处 http://kernaling-wong.iyunv.com/blog/2017985