系统怎么这么慢？？？
甲方的人又从楼上走下来，边走变嚷嚷这慢慢慢。
嗯？怎么可能，昨天不是放大连接池了么，为什么还慢？
迅速拾掇出昨天的定位步骤，三步下来，不属于任何一种情况：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，重启，得意。。。
后面还有硬仗等着呢。。。