一次性能测试的分享
性能测试分：前段时间出差上海做了一次性能测试，在这个过程中遇到了较多的困难，也收获了很多，在这里想把解决问题的方法分享出来。
去现场之前了解现场的基本情况。这里主要是分为两点：
（1）客户生产环境的软硬件设施
（2）压力机的软硬件设施
对于客户的生产环境的软硬件设施我们一般可以从生产环境的网络拓扑图入手，对生产环境的网络架构有一个初步的认识。
这里有两点需要大家特别注意的：
（1）客户生产环境是否采用了负载均衡，以及所采用的负载采用的算法。这里有一种算法是大家需要注意的：源地址哈希法，因为采用这种算法时，负载均衡器会将同一IP的请求映射到同一后台服务器进行处理。上次出差时客户现场使用的正是这种算法，压力机的请求却都是被服务器B处理的，而且客户也未告知采用了负载均衡，导致只监控了一台web服务器A，但是因此得到的监控数据均是0，导致不得不重新压了一遍。
（2）服务器采用的操作系统。不同操作系统所需要的监控软件有一定差异，对于windows一般采用LR自带的监控就够了，但是如果是linux系统我们一般会使用nmon进行监控，因此根据不同的系统，做好不同的监控软件准备是我们到客户现场之前所需要的。
对于压力机的软硬件设施我们一般需要注意的是：
（1）压力机采用的操作系统版本。现在大多使用的LR版本还是11，LR11是不兼容win7以上的版本的，上次出差就是因为客户压力机采用的是win server 2012 导致不能兼容LR11导致浪费了一天时间来解决版本不兼容问题。因此根据要使用的LR版本让客户提供相应操作系统的压力机。
（2）压力机测硬件设施主要关注对象为：压力机的内存。在执行场景过程中，随着虚拟用户的上升，占用的压力机内存也会越大，LR官方提供的数据是一个虚拟大概吃掉3-5M的内存，因此根据客户的需求评估需要多少压力机是我们工作的前提。
（3）注意压力机和服务器之间的网络连接，压力机和服务器之间最好是局域网连接，否则在压测时很容易造成网络流速达到上限，不能分析出系统的瓶颈所在。
测试过程中需要注意的地方：
（1）压测过程中，开始人数从一个比较小的数值开始。在压测过程中，人数直接从100开始时，发现场景开始时的tps一直没什么变化，分析了许久才想明白应该是一开始就达到了系统的瓶颈，然后重新压了一次，人数从0开始，到50的时候系统网络流速就达到了极限，怪不得出现第一次的哪种场景。
（2）性能测试的关键点在于产生有效的压力，因此，在这过程中，参数的取值模式很重要。在一次压测过程中，通过的事务达到了1000，但是数据库里只增加了100条记录，后来分析一下发现由于参数化时，参数类型选的是：unique+once 导致每个虚拟用户只能取得参数列表中的一条记录，事务其实并未执行成功。后来将参数类型改：unique+each iteration 时，问题得到解决。
（3）对于数据缓存的选择。在压测过程中，发现当50人并发登录时，网络流速达到120MB/S，后来检查后就才发现脚本里包含了太多的JS，CSS，图片的请求，这些数据的请求导致了网络流速较高，因此在压测过程中如果不是最大压力情况下，可以选择不录制JS，CSS，图片的请求连接，可以通过设置LR中关于设置清空缓存的方法进行解决，这里就不再赘述。
帮顶，最近也一直在搞性能方面 :victory: :lol 支持分享
页:
[1]
