在进行性能测试时，如果发现服务器的各项指标都比较低的时候，就应该考虑测试带宽的限制问题了。 以下是某性能测试遇到的问题
性能优化点：
1、动态页面静态化
2、网络io 与 磁盘io 比较
3、
这两天在为进行过调优后的服务器做性能测试，在对其中一个详情页面进行压力测试的时候，测试结果为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的结果，其实我已经相对满意了，因为考虑到实际应用场景，在最有可能出现峰值的情况下，实际大部分用户只会访问比较少数相同的页面，而我们对于同一页面的请求都进行了静态化的处理，实际上除了第一次请求外，其他的请求都是直接访问静态页面，因此实际能承受的压力远远不止于此。