搜索性能调优

近期发布单量增长过快，当发现问题时，线上的发布单总量已经超过1200万，搜索整体性能下降，前台S站点响应速度变慢，由于前段的Varnish反向代理缓存，大部分情况下用户响应还是比较快的，但在未命中缓存的情况下，前端响应非常缓慢，单条请求至少在40秒以上，S站点的各项性能指标已经临近极限。

 

对此，我们采取了一系列的改造调优措施，整体优化过程分为好几个阶段，分别针对前个调整后出现的情况通过分析采取下一步的动作。

 

一、发布单量大造成搜索速度慢

问题：

发布单量过多后，搜索速度偏慢。

解决办法：

针对isearcher的现状，对类目以及关键词索引实行分片处理，将目前的大游戏类目索引，小游戏类目索引，关键词索引，拆分成3片大游戏类目索引，3片小游戏类目索引以及6片关键词索引，紧急处理后，经过测试部门测试关键词提高两倍，类目提高一倍搜索速度。S站点的响应时间得到提升。如下图所示，初上线时，压力情况得到缓解。

 

二、S站点web打开连接数过多

问题：

S站点web在isearcher分片上线后，由上图可见，在线上流量低谷期，响应迅速，但在高峰期时，S站点出现404无法响应的错误，初步分析，在高峰期，由于搜索处理能力提高造成S站点打开连接数过多，来不及及时关闭，IIS线程池调度开销过大，服务器资源耗尽，出现404错误。

    解决办法：

鉴于S站点的连接关闭问题，针对此情况，临时将搜索端使用的软件负载haproxy调整为长连接模式。S站点的问题得到解决。

三、但新的问题又出现了，S站点的问题得到解决了，搜索这边的问题又出现了，haproxy调整为长连接模式后，Isearch出现“打开文件数过多”的异常日志。So，

问题：

长连接后，isearcher打开文件数过多，其实就是tcp连接过多。

    解决办法：

       Haproxy长短连接模式都使用过了，问题是此消彼长，结论是，我们对haproxy的应用可能还没有非常熟悉的地步，临时研究探索肯定是来不及了，于是，决定紧急使用我们非常熟悉的，而且在线上大规模应用的，非常可靠的f5硬件负载。

   

四、配置f5负载，S站点接入

问题：

    当我们紧急将搜索的Isearch应用转换为F5硬件负载后，S站点迅速切换到前台还是出现打开文件数过多

解决办法：

    通过当前连接数的排查，发现，所有异常日志均指向为原先的haproxy建立的连接，经过确认，发现原有的haproxy仍然存在前台的关联营销应用关闭haproxy,问题解决。

五、AMS接入F5负载

问题：关联营销接入F5负载，得不到返回数据，排除了网络设置问题

 

解决办法：

最为纠结过程，当S站点接入F5以后，随即Ams也转接F5，但令人匪夷所思的一幕出现了，AMS是与S站点调用的同一F5映射地址，在排除确认网络通讯无误的情况下，AMS始终得不到Isearch的响应，没有数据返回。而且搜索后台管理服务器直连Isearch服务器，也一样得不到响应。

这是怎么回事呢？通过不断的在分析，尝试，最终发现一些端倪，当Isearch的Web服务宿主容器Jetty的线程数放大后，AMS开始收到返回数据了

六、Isearch服务器CPU锯齿非常严重

问题：

当Jetty的线程数放大后，isearch的服务器CPU使用率彪高，且波动情况非常之巨大

 

Cpu使用过高，负载不均匀，部分机器cpu在很短时间内达到90%以上，其他的只有20、30%左右。

解决办法：

   由图形观察，基本上都能够看出来，这是非常不正常的，于是又经过不断的分析尝试，最终将F5的入口连接数限制，并将Jetty的线程数调低，于是一切OK了，整体平稳，S站点与AMS站点性能各项指标非常出色。

  

Isearch服务器CPU非常稳定

 

七、f5连接限制与Jetty线程池设置调优

问题：

   随机而来的问题有：

l  3段服务器没有返回消息

l  线上偶发固定发布单号搜索不到

l  部分情况下应该有结果返回但提示无数据

l  Isearch服务器的CPU虽然稳定，但是还是比较高

解决办法：

于是，我们来分析一下F5连接限制数与Jetty线程池设定之间的关系

l  首先我们确定一点，F5与Jetty直接建立的是长连接关系，既然是长连接，那么就相当于数个直连通道，没有连接创建销毁的开销

l  那么为什么3端没有返回呢，其实症状和先前AMS接不进去一样，因为Jetty的处理线程小于F5创建的线程数，虽然F5与Jetty之间建立了通道，但是这些通道有通路也有死路，通路都被S站点占用，一旦新客户端接入，F5必定调度一个全新的通道，而这条通道是死路，因为Jetty根本没有多余的线程用来调度处理这条通道的请求。

l  于是，我们可以得到一个结论：jetty处理线程数一定要大于F5的连接限制数

验证这个问题，我们将后端Jetty的线程池调整为比F5连接限制数略大，结果，奇迹出现了，前3个问题解决了。

但是搜索服务器的CPU虽然平稳，但是锯齿却比较严重

 

l  接近成功了，先前我们曾经试过，将Jetty的线程数调低，当这个线程数接近CPU核数的时候，CPU的表现就会异常的问题，于是我们可以补充另外一个结论，综合起来看，f5连接限制与Jetty线程池设置调优必须同时满足一下两个条件：

1.   F5连接限制数必须小于Jetty线程池设置（解决请求无结果和新客户端接入不响应的问题）

2.   F5连接线指数和Jetty的线程池大小设置必须结合服务器CPU核数，确定在一个合理的范围之内

我们根据这两个条件去进行调优，于是，效果出现了

 

而前端应用，速度大幅度提升，没有队列等待，线程等待时间为0，处理速度大部分在100MS以内，吞吐量提升，后端搜索Isearch平稳，CPU稳定。哦耶！

   

RequestExecuting   工作线程数

RequestWait Time请求在队列中的等待处理时间，越小越好，0是最佳

RequestCurrent   当前请求数

RequestQueued    当前队列请求数（当前请求数=队列数+处理线程数）

CurrentConnections 当前连接数

CurrentISAPI Extension Requests 当前由服务同时处理的ISAPI扩充请求数，这个值一般与framework 下面的Request Current很接近。这个值的大小要根据实际情况分析以判断是有问题。