服务器压力上不去缘由分析

百兆的带宽在理论上1秒钟能够传输12.5MB的数据，可是考虑到干扰因素每秒传输只要超过10MB就比较正常啦。千兆带宽每秒传输是100M。

http://www.cnblogs.com/candle806/archive/2011/04/02/2003828.html

经过分析，处于峰值只有网络带宽，为90%以上，而对比此处的吞吐率值恰为95MB/s左右，1Gbps的网络带宽传输速率为128MB/s，从而代表因为吞吐量过大，占用了大量的带宽资源，致使后续的虚拟用户没法获得服务器的资源，而导致请求被拒绝。从最后的页面响应时间来看，系统的压力并无被承接到页面上，而是因为过大的吞吐量吞噬了网络带宽，致使最终没法有效地完成测试任务。

http://www.xinfengit.com/200907/1848581.html

在性能测试过程当中，常常会遇到数据库CPU资源利用率上不去

一、网络带宽问题

1.1被测试环境和lr用机都在百兆带宽中

 

1.2被测试环境和lr用机不在同一带宽中，被测试环境在千兆带宽环境中，lr用机在百兆带宽环境中

 

2.Controller机器在百兆带宽中，被测试环境和lr压力发生器在千兆或以上带宽中

能够查看被测试环境中的交换机的传输速率是100Mbps仍是1000Mbps。

TP-LINK TL-SF1016，传输速率：10/100Mbps

三、数据量问题

3.1网络没有问题，吞吐量甚至超过100M，可是后台服务器资源仍是比较低。

数据库中基础数据量比较少，几乎是空的数据库，这样数据库CPU利用率也上不去

3.2数据库中的数据量虽然比较多（100万笔以上），可是在性能测试时真正用到的用户所关联的流水比较少，或者根本没有关联上流水。好比：150多万的交易流水，目前用户表有500个用户号，其中有200个用户号关联到了流水表中的数据，而测试时用到了50个用户。数据库CPU没有上去，先要排除网络和数据量的限制，而后要查看这50个并发用户是否都关联到了流水表上？每一个客户号关联了多少流水（大于2000，小于10万，太大的会不现实）？

 

四、JDBC链接池限制

以上网络和数据量都没有问题，则会考虑交易到数据库的链接数是否有限制，和数据库操做的那些交易的SQL请求根本没有到达数据库服务器。咱们能够经过中间件的控制台查看JDBC的最大容量（此链接缓冲池可容纳的最大物理链接数）

4.1数据库JDBC链接池限制，设置的原本就小，weblogic默认最大容量为50。

 

4.2若是一台应用服务器上是多路进行部署的话，查看各路JDBC链接是否均衡

 

五、应用程序问题

处理能力真的达到了极限==

 

六、性能测试脚本和数据问题