这段时间开发和FUTE(功能测试)结束，做产品的PETE(性能测试)，对于测试开始前应该做的test bed的检查工作，写一笔，未来继续添加：

　　[背景]

　　PETE前的检查工作看似简单，然而其必要性和重要性都值得关注，避免在调试那很久软件参数，抓落那n把头发的时候，结果却发现硬件条件早就不能支撑,白白耽误时间，而Software Developer自己做PETE的时候(至少我是)，最容易忽视的就是硬件。

　　[硬件检查]

　　1.Check CPU,MEM of all the test objects

　　2.Check Storage efficiency : multipath -ll; hdparm -Tt /dev....

　　3.Check Network using tools like iperf

　　[软件设置]

　　1. 线程不是越多越好，线程切换，资源锁等因素的影响使得性能的提升和线程的数目之间不会是一个正相关，特别是线程的数目达到一定的值以后，更多的线程可能反而帮那倒忙。最好是先根据系统整体输入，各个模块的输入，模块内部线程对输入消息的处理模型：阻塞，非阻塞，同步异步等等，对线程数目做一个预估计，然后在这个值的基础上进行调整，不然在多进程，多线程的架构下面，单单靠试错的方法，很可能按下葫芦浮起瓢，如此多的调整参数，非把人搞疯不可。

　　2. 理清楚系统内部的一个性能瓶颈所在之处，完全靠PETE的结果来反映是不现实的，一是需要比较长时间PETE的结果来梳理出结果，耗时；二是很可能系统的设计让消息在各个模块里的处理时间完全不可见，缺少像transaction(Glance ARM)的runtime统计支持，当然也可以不使用工具，自己造轮子比如对于每个消息用唯一的ID号标记，同时在模块的输入和输出的时候对消息做 event log，支持这种log的开关可配置，既方便调试，也可以在部署到客户关闭。有的同学说那，也可以使用宏开关，对于实验室版本和发布版本分别打开或者关闭，那就是具体问题具体分析那嘛。

　　3.当你在使出浑身解数，把所有可调的东西全调那n次以后，还是对PETE测试结果非常不满意，性能提升完全毫无希望，哎，还是重新考虑架构是否合理吧，选择的库性能是否经过测试，虽然这些一开始的时候就应该考虑到，怎么说呢，一开始就能考虑到的估计已经是走出软件作坊的那吧。谁说世界五百强的Software就不会是个作坊？:-)