性能调优 - 第二仗

系统怎么这么慢？？？

 

甲方的人又从楼上走下来，边走变嚷嚷这慢慢慢。

 

嗯？怎么可能，昨天不是放大连接池了么，为什么还慢？

 

迅速拾掇出昨天的定位步骤，三步下来，不属于任何一种情况：cpu、内存、正常！ tomcat没有溢出！！没有连接不够用的异常！！！

 

这里需要介绍一下我们的系统架构，前端apache负载均衡到后面的四个集群节点，apache独立部署在一台主机上，四个节点分别部署在两台主机，每台主机各两个。

 

用户反映说登陆页面打开要好长时间。静心想想这个过程吧。

 

请求到了apache，apache根据负载均衡策略，分发请求到后面的四个节点。现在是页面打不开，那也就是说服务久久没有响应。无非是两种情形：

一、请求在apache这里排队，没有及时分发到各个节点

二、请求在tomcat这里排队，没有及时响应

 

好吧，来证实一下我们的思路哪一个是正确的。

 

由于刚好我先登陆了节点所在主机，就先从第二个假设开始验证吧。

 

查看节点ajp端口的连接数：netstat -an|grep 8501|wc -l

 

此命令一出，可迅速判定是不是tomcat请求排队。

 

分别对四个节点做了此番测试之后，终于发现，节点一有700多个established状态的连接

而其余三个节点的established状态的连接仅有几十个！！！

 

至此，至少可以说明一个问题，apache负载没有分发均衡！！

 

查看apache的分发策略，我们采用的是亲合式。stick_session

 

此方式的好处是请求一个主机之后，apache会设置cookie到客户端，以后客户端的请求就会向cookie中指定的节点固定发送。

比如，客户Ａ访问的是节点一，那么以后客户A只会被分发到节点一上。

 

结合现在的状况，说明很多客户的cookie都设置成节点一来响应，所以apache也无能为力，只能分发到节点一。

 

至此，你可能会说，为什么不用回话复制的分发策略呢。哎，由于甲方要求不让使用tomcat，而是使用的一个收费的对tomcat进行了包装的一个第三方产品，此产品只支持亲和式的分发策略，身不由己啊。。。

 

解决方案：

给apache配置一个新的请求控制器，对于首页的请求，即登陆系统经历的第一页面，让此控制器来处理。此控制器不采用亲和式分发策略，所以一旦客户请求这个页面，那么肯定会重新设置cookie到客户端，而非之前客户端缓存下的节点。这个办法相当于我们帮助apache做了一次分发。使得客户请求系统时，总是能获得一个信息cookie，这样可以一定程度上辅助apache重新做一下分发。

 

修改apache配置：worker.proerties和http.conf，重启，得意。。。

 

后面还有硬仗等着呢。。。