性能测试压力实录

本次性能压力测试的一个记录，，并没有生成一个完成的性能测试报告，但在这次实战中，还是有很大的收获，简单记录一下本次性能测试的过程，

1. 1案例详情
   1. 项目背景
      1. 本项目是【XXX大会】，参与人数有6/7万人，在活动高峰期，会有比较高的并发量，又因为是Gov项目，对于项目要求还是比极高，不能出现页面有问题的情况
   2. 预期设计计划数
      1. 正常情况下，产品会给出预期的并发数、平均响应时间，和QPS，但是也有一些产品并不是很了解这些数据，只是给了个要去，别崩就行
2. 工具的选择
   1. 遇到的问题，关于Jmeter，常用的工具，这次并没有去用
   2. 用的是京东云自己二次开发的【云圭】（打下广告），其他大厂也有，没太多时间去了解，应该都很不错
      1. 二次封装Jmeter+Grafana  ，既有Jmeter的性能、也有Grafana  图形展示，很秀
      2. 图形结果特别好观察得出结果，Jmeter的数据表没有那么简单的去理解
      3. 云上操作，可以记录每一次的执行记录，时间次序、对比每一次的效果、日志追踪，都比本地的Jmeter好用，毕竟Jmeter一关闭，啥都不好好找
      4. 云机器，不用在自己机器上跑，不用占用自己的内存，最大限度的规避了本机的网络影响，虽然压发的机器可能一般，但能至少2万的并发，性能也是很高的
      5. 虽然还有很多不足，但对于一些常规的压测，还是很棒的
3. 测试的数据，
   1. 策略：先找一个主要的接口进行压测，一个性能达到要求后，然后对其他页面再进行压测
   2. 单个接口查看瓶颈
   3. 页面分为H5页面和Pc 端，主要是H5页面，但是访问的后台都是一个，主要是已H5为主，
4. 数据分析
   1. 提升压测数据，QPS=并发数/平均的响应时间，而且，
      1. 如果不知道预期的QPS的设计标准，以前也没有对系统压测过，那么可以小计量，从200的并发，逐步提升，
      2. 评判标准也很简单：就可以这么去压测，在保证200响应正确率不低于99.99%的情况下，响应时间不高于1s,逐渐加大并量,随着并发量的不断提升，QPS就会不断的提升
      3. 在不断压测的过程中，随着并发量不断的提升，系统处理事务的性能越来越低，CPU内耗加剧，磁盘写入量也不断的加大，这个时候就会出现一些数据的变化，比如200的正确率开始下降，响应时间逐渐升高，QPS也在不断的下降
      4.   
      5. 
      6. 当出现这些问题，那么系统的瓶颈就在该数据的周围了，可以找一个点，比如并发600的时候，200返回率99.99%，当并发数据增加到700,200返回率下降到80%，正确率下降，响应时间开始提示，那么系统的瓶颈可能就在600-700之间，然后得到一个此时的QPS数，这样的数据是有问题的，应该要拉着研发去排查问题
   2. 问了一些大牛，对于并发数（Jmeter中的线程数），都是500起步，所以从500开始测
      1. 参数：并发数：500；思考时间：5秒（更符合人的操作特点，不可能不思考，只是刷接口）；持续时间：1分钟（在系统没有被压测前，先压测看一下情况）
         1. 结果：响应时间一般在500毫秒以内，毕竟并发数并不是很大，200响应值肯定是100%
5. 4.性能的提升
   1. 从多方面去排查问题，随着并发量不断上升
   2. 硬件：
      1. 如果家里有钱的话，先加硬件，看一下效果
         1. 增加主机、提高带宽（100->200）,增加负载均衡（LB），增加Nginx转发,这些都可以先添加
      2. 如果都加上去了，效果比较明显，那么问题就在硬件上，然后再继续提高并发量，找到性能提升后的瓶颈
      3. 如果加上去之后，收效甚微，并发量提升了1倍后，错误率又开始上升，其实1000多的并发量并不是很大，所以还是要继续找系统的问题
   3. 软件
      1. 软件存在会有很多的问题
         1. 代码：如果你的代码阅读能力比较好，那么就去读代码，一些逻辑的处理是否正确，代码的方法是否合理，是否会较多的占用性能等
         2. 数据库：具体的库设计并没有仔细看，但大概看了一下，设计数据库的时候，并没有找到数据库的索引，具体的索引自己可以百度一下，简单来讲，就是在查询数据库的时候，会优先从设定的索引字段中筛选数据，增加查询的速度，如果没有索引的话，需要把整个表数据都要遍历一遍，再找到符合要求的数据；索引的效果还是很明显，虽然索引会占用磁盘大小，但现在能花钱解决的问题都是小问题，不怕占用，只求效率
         3. 
         4. 日志读写：每个系统不同，可能没有这个问题，但这个问题却是我们系统的最大瓶颈，为了避免出问题，研发在没有个接口请求中都加了logid，所有的请求都存到数据库中，为了方便查询日志；而问题就出在了这里，大量的接口请求不断产生日志，这些日志又不断进行读写，系统大量的内存都用来读写日志，对系统I/O流占用了较大的内存，
            1. 系统日志有写入的策略，比如常用的log4j,就可以设置不同的写入要去，可以进行跳转
            2. 把日志的写入级别降低，系统的QPS直接上到了4000多，可以确定，系统瓶颈大概就是这个原因
            3. 问题好改，主要是要发现问题，这个问题发现，很大程度上需要研发甚至是架构去排查问题，他们更了解这个系统的整个架构，他们知道坑在哪；当然，如果你不了解那就多看一些资料，多董一些知识，考经验也能砸出花来（更新一下，如果要做真正的性能测试，测试要是要读懂研发的代码，了解系统的架构，如果不知道系统架构每一个模块是做什么，即便是拿着各种工具，对系统一通压力测试，也只不过是性能测试中的黑盒测试，通过数据发现整个系统的问题，并不能更具体的发现系统的核心问题在哪，所以测试也是要读懂代码和架构，即便不懂，也要往这个方向发展）
            4. 日志也可以进行批量读写，而不是产生一条就写一条，最近比较流行读写分离，可以了解一下
         5. 系统缓存机制，系统每30秒就要更新一下缓存，重新读取数据，这个做的好处是可以及时的刷新数据，但是对系统的性能有一定的影响，不断清理缓存，再重新加载数据，服务会有一定的影响，如果不清除缓存，直接读取，速度可能的会比较快；早期像淘宝，在更新卖的服务的时候，都是晚上12点更新，让后一天都不操作数据，就可以减少重新获取缓存的机制；我们就把读取缓存的时间改到3分钟读取一次，性能提升了一部分
      2. 提升后的效果
      3. 
      4. 
6. H5页面测试
   1. 遇到的问题，主要是页面。那么前端页面会不会有其他的瓶颈，需要分享
   2. 从多个方面去排查
      1. 手动检查
         1. 图片大小，只要是不影响质量的情况小，越小越好，如果要是几M 大小，肯定会有很大的影响，
         2. 图片格式，png格式的图片大小占用的存储要大于jpg，格式可以限制一下
         3. 页面发出去的请求，马虎的研发可能会对没有用请求多次请求，增加了请求次数，影响了性能数据
      2. 工具检查：
         1. 压力工具选择，https://www.googlespeed.cn网上有很多，这个也可以
         2. 给的数据还是比较客观的，可以对应的优化
         3. 
         4. 
         5.  
7. 实际需要考虑的其他问题
   1. 除了系统以外，还是要考虑一些实际的项目可能存在的问题
   2. 网络、
      1. 带宽、较大的访问量，对网络上传下载有很大的要求，比如，首页背景已经压缩了多次，但还是有300kb，较高的请求量对带宽有一定的要求
      2. cnd域名解析，用户在反问域名时，会找到最近的cdn进行域名解析，解析域名以后，再进行访问IP服务器，如果请求低离cdn较远，会影响访问的时间，解决这个问题，可以增加cnd节点，加快域名的解析
      3. 距离：网速都很快，很多时候是可以忽略的因素，但如果比较远的话，需要考虑；本次活动在大西北，而我们最近的服务器在北京，从西北发送的请求到北京，再由服务器处理，再返回，这个时间还是要考虑其中的
   3. 大牛也讲了一句，其实普通的压测，能优化的策略很多，比如，如果访问量特别大，那么就增加IP，同一个域名，分到不同的IP上，不同的机器在服务，，压力大，就不断增加机器，虽然很笨，但是能解决问题（呵呵哒一下），这又考虑不同系统之间的系统协同合作，这也是平台的一个一个升华
8. 叨逼叨，叨叨一句，工具会的很多，有时候并没什么卵用，之前就是唯工具论，工具会的多了，自我感觉很牛，很炫，什么都会用，但是到实际项目的时候，才发现，工具和技能并不是最重要的，主要的是有思想流程和方法，知道如何压测，如果使用数据，如何分析，即便没有工具，自己写个脚本，也能发现问题，或许这就是万变不离其宗