性能测试之初见

       接触性能测试一段时间，但是介于项目忙碌而无暇总结，从2年前的stage测试到如今web测试，对性能测试逐渐的有所认知。什么是性能测试，个人认为以考量系统响应时间和业务完成时间的测试都可称为表现性能，系统的瓶颈或拐点的验证测试即服务响应慢、服务假死等诸多情况的关注称为服务性能，即通常的负载压力测试，目的是为了系统在性能和可扩展性提供有力支撑。

       性能测试的难度在于业务分析和瓶颈定位，性能场景的建立依靠对业务的深入分析，如登录场景通常情况是打开首页输入用户密码登录到首页，设计场景时应当以用户角度来分析那部分性能对客户影响最大，从体验角度来看，更关注从输入跳转到首页的时间，当然具体系统具体分析，像长时间在线系统如oa，可能session设置会在小时级别而且会有定时的在线轮询，而一般的网页在不操作时并不会进行服务器链接，所以不同系统的响应要求也不尽相同；

     随负载增加性能不再提升或在可承受负载内性能出现异常（内存泄露、网络阻塞、数据库链接用完等等）这时候就出现了瓶颈。

        如何分析，首先确认小剂量测试情况下系统表现良好，然后在负载压力下跟踪应用系统的各种资源使用情况：CPU、内存、IO、网络，从环境层面服务层面应用层面进行逐一剥离：

1、环境层面确认服务器硬件正常（曾经测试过nfs系统遇到过类似情况集群服务器中偶尔会有服务器硬盘异常），

2、网络环境正常（如高负载情况下服务器多网口绑定是否正常，交换机或路由器trunk正常等），

3、服务层面主要是中间件的配置（操作系统可访问tcp句柄数，数据库共享内存，session数量，并发数等，服务的内存设置常见IIS只能用系统一半内存，tomcat、weblogic等服务最大线程个数访问连接次数最大队列数，JVM设置内存大小垃圾回收方式，数据库链接池大小等），

4、应用层面如服务死锁内存溢出数据丢失（服务死锁在高并发时发生几率较高，这跟系统实现有很大关系为了保证数据正确保存而程序又不依赖第3方工具如存储过程，往往将事务固化在程序内部，这样就出现上面的情况，当同一事务进行连续数据库操作，这时可预见的情况，多个事务都在往同一字段中插入数据，而写数据库存在锁表情况，如此就出现了某个事务永远在等待上一个事务的可能，这里可能涉及到排队论，鉴于不是很了解就不多说了，于是就出现了死锁现象，

        当然工作中还遇到更严峻的事务问题，丢数据文件情况，曾测试过事务为了支持lusence，将文件写盘，标识入库，事务并发锁写的较挫，导致高并发时会出现文件丢失情况；内存溢出情况定位需借助外部工具定位代码行）。

  

未完待续。。。