转：性能测试中带宽的影响

这两天在为进行过调优后的服务器做性能测试，在对其中一个详情页面进行压力测试的时候，测试结果为110TPS，对于这一结果我们是非常不满意，随后又在多个不同的模块下进行测试，结果都非常的相近，然而在压力测试过程当中，服务器的资源消耗非常低，由此我们可以看出，服务器远远未达到压力的极限，而应用程序应该不会有问题，如果是程序问题，服务器资源绝对不会有那么多空闲。

问题到底出在哪里呢？我们web服务器的架构为nginx+lighttpd，于是我们一层层进行单独测试，发现结果仍然是一样，4核的服务器CPU资源损耗仅处于20%左右，我们又对单一的静态页面做压力测试，发现结果仍然是差不多，并没有太大的提升。无论动态还是静态页面，结果都一样，这就更加肯定了我们的结论。排除了应用程序的问题，那问题就应该出在IO那块，再通过磁盘监控，发现磁盘IO的损耗也非常的低，但是我们却有一个意外的发现，多次测试的结果中，网络IO的流量都是处于12M左右。

看到这里，我们心里就豁然开朗了，问题原来是在这里，我们一直都把重心关于于服务器本身的性能调优上，却偏偏忘记了网络带宽的因素，虽然我们测试服务器的网卡是100/1000M网卡，然而我们却是将服务器部署于百兆局域网内，而100M带宽的实际传输速度刚好是介于12M左右，由于我们终于发现瓶颈是在于网络带宽，而非是服务器本身的性能上。于是二话不说，我们立刻将所有的测试服务器以及客户机都连接在同一千兆网内，尽可能降低网络带宽的限制。

成功搭建好环境之后，再进行测试，结果果然如我们所料，静态页面的测试中，最快的模块测试达到了600TPS上线，而此时的网卡流量已经达到了50M左右，而由于多个模块的页面大小并不相同，TPS的结果也各不相同，但是网卡的流量却都处于50M上下，然而1000M网的理论速度是可以达到120M左右，50M的实际速度远远未到此数，也许达不到理论速度，但是相差应该也不会太多，于是我们尝试从两台服务器之间互相copy大文件测试一下实际速度有多少，而最终的结果也是和我们测试web服务器的结果一样，也是在50M上下，因此又一次证明了IO是一个瓶颈，只是还无法确定是磁盘IO还是网络IO，由于时间比较紧，我们就并未在此问题上多做纠缠，因为这只是对静态页面的测试，实际运行过程当中，真正的瓶颈应该是在应用上，因此我们再次将重心转移到动态页面的请求上。

再一次对动态页面进行压力测试，这次我们对各个模块测出的平均结果处于200TPS上下，而网络流量仅仅处于30M左右，此时服务器的资源占用率已经处于80-90%之间，基本已经是处于满负荷状态，纯动态页面200TPS，不算高，程序本身还有很大优化的空间，不过五一过后就要正式上线，此时再进行优化已经来不及，不过对于纯动态请求200TPS的结果，其实我已经相对满意了，因为考虑到实际应用场景，在最有可能出现峰值的情况下，实际大部分用户只会访问比较少数相同的页面，而我们对于同一页面的请求都进行了静态化的处理，实际上除了第一次请求外，其他的请求都是直接访问静态页面，因此实际能承受的压力远远不止于此。

最后，我们针对实际应用场景，通过loadrunner模拟真实访问情景，结合所有的测试对系统进行综合的测试，对各种情况进行百分比设定，尽量模拟真实情况，测试的结果处于400-500TPS，而网络流量也到了之前测试的上限值，再考虑到实际情况中，客户端对静态资源还会进行缓存，应该还会有相对大的提升，本次的结果相对真实，而我也比较满意，在下一版本中，应该会针对应用程序再次进行优化，相信还会得到一个不小的提升。

最后，在此对TPS进行一下解释（摘自网上的解释，懒得自己写了，我是个懒人）：
TPS是TransactionsPerSecond的缩写，也就是事务数/秒。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数，最终利用这些信息来估计得分。客户机使用加权协函数平均方法来计算客户机的得分，测试软件就是利用客户机的这些信息使用加权协函数平均方法来计算服务器端的整体TPS得分。

注：Loadrunner中还有很多其他的评测参数，不过我个人认为TPS更具代表性，因此只在此用TPS作为评核依据。