性能调优 - 第二仗

系统怎么这么慢???

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

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

迅速拾掇出昨天的定位步骤,三步下来,不属于任何一种情况: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访问的是节点一,那么以后客户A只会被分发到节点一上。

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

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

解决方案:

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

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

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

相关推荐