性能测试总结（一）

一.性能测试小结

在性能测试之前需要对被测试的各种资源有一个基本的测试结果的基础经验的认识！

前端（根据PageSpeed评测各项指标的性能）：

1. 图片大小，压缩
2. 传输压缩gzip
3. 样式文件合并
4. js文件合并
5. 缓存

后端（不同的并发下条件，不同的数据基数的基准性能。待完善。。。。）：

1.   Web服务器（IIS，Tomcat，Apache）
2.   数据库（Sqlserver，Mysql，Oracle）
3.   Nosql（redis，mongoDB，TT）
4.  通讯（Http，hessian，webservice，Tcp）

二.性能测试准备

1. 目标：在什么环境中，什么压力情况下，达到什么样的性能指标（均值，峰值，响应时间，资源使用要求）三个问题。第一个问题环境各个公司都有不一样的机器资源。第二，三个问题需要通过业务量统计推算tps均值，峰值.响应时间按照具体业务需求容忍度来确认。
2. 环境：搭建各个不同的站点，服务器，数据库。
3. 数据：铺设测试数据，可以通过datafactory或者自己中间层加sql准备需要的业务数据。
4. 场景：根据业务需求抽象出性能测试点。
5. 执行：可以通过不同的项目需求在不同阶段进行，底层接口使用lr的.net或者java或者C++直接压测，对于web直接lr的http进行压测。

三.影响性能的相关开发知识

1. 数据结构：数组，列表，堆栈，List，Dictionary，hashmap，hashtable……..等，这些数据结构是为了在内存中存储数据，数据越多，内存占用越多，但是同样的数据是否可以用简单经济的数据结构存储呢？
2. 算法：消耗cpu,小到最简单的循环，大到对象转换，数据处理，多线程并发处理，死循环，线程滥用都是导致性能底下的原因。
3. 网络：在网络上传输的数据大小，发送方式都影响性能。比如数据大小，tcp在发送数据是根据协议头，协议数据体组成的，同样的协议头用int或者char都可以，但是char要比int少传3个字节，节省流程，提升速度。发送方式的话发送到模式比如同步发送和异步发送对于客户端的影响完全不一样。
4. 减少装箱和拆箱操作，值类型和对象类型相互转换，堆栈和堆交互需要大量的计算。
5. 字符串String，StringBuild合理的运用，如果涉及到大量的字符串日志记录，使用StringBuild单个对象，String需要申请N个对象。
6. 避免多重循环处理，循环套循环.
7. IO处理，在真正需要的时候打开和关闭，节省连接的资源。，比如数据库打开，关闭，文件的打开，关闭，socket打开关闭。
8. 多使用存储过程，因为sp是预编译的，比通过用sql重新编译，执行要高的多。
9. 索引，提升查询速度，但是牺牲内存，降低insert效率。
10. 库涉及，主从分开，读写分离。
11. 表设计：根据业务拆表，根据时间，数量拆表。
12. 进程是什么：exe？装载资源的容器，包括dll，图片，代码，数据。
13. 线程是什么：线程是进程内活动的单元，进程内由主线程驱动，完成某些计算或者创建子线程处理计算。线程并发能提高处理的效率，是不是越多越好呢？并发的本质是什么？cpu的切换，那如果太多的线程导致cpu忙于切换到话呢？
14. 线程池：原理是什么？系统维护的线程资源池，可以向资源池申请，用完了可以自动回收。可以合理使用线程资源。
15. 同步，异步区别是什么？同步使用适量的并发取得最好的效率，异步使用线程数取决于cpu内核数，几核心就几线程效率最好。
16. 单件模式：为了减少某些连接资源，需要单件，就是整个系统中只有一个实例来处理数据，比如web上有很多消息到底层只通过一根通道发送消息就需要用到单件。
17. 生产者，消费者模式：生产线程生产出数据，消费线程处理数据，如何生产，如何消费需要注意，新增线程取数据，新增线程处理数据？

四.性能定位

1. 首先暴露问题，并发情况下，报错？很慢？如果报错，日志中会显示相应的错误信息，先解决并发引起线程安全的错误，相对比较容易解决。如果还是很慢的话继续往下。
2. 请画出对应并发操作的背后牵涉到的所有节点的架构图，webserver，应用server，缓存，db。。。。。
3. 排除环境和客户端问题，在上面的结构图清楚的前提下，客户端发送模拟业务的请求，确认环境中的每个环节本身是不是本身资源就接近瓶颈了？减少客户端多余的请求，发送真正和模拟业务相关的请求，其他的都剥离掉。比如js，图片等资源本身请求因为环境很慢，导致客户端发请求发不上去。网络限制，不同网段之间是否有网络流量限制，网卡流量是否限制导致客户端不管怎么增加请求都上不去，服务器资源照样很低。配置问题，是会因为配置低而导致性能低下，但是一般不会出现超低的现象，而是优化更好的处理，比如tomcat连接数配置，内存占用，mysql的连接数，内存占用，日志处理。
4. 如果排除环境和客户端的问题后还是很慢，在并发压力查看每个节点上的资源使用情况，如果最终结果很慢，必然在某个环节上会暴露出资源异常情况，如果没有发现，应该是架构图上还缺少节点，对所有节点进行资源使用情况观察（结合业务数据走向）。目的是锁定某个节点的资源使用异常，比如说内存，cpu，io很高，如果确认到cpu或者内存问题需要和开发讨论算法，原理，来龙去脉，再推算出资源异常的原因，一定需要多沟通知道开发的具体处理方式才能对应处理。比如说过量的穿透db做数据库io导致数据库服务器资源异常，是否可以部分缓存？比如过多的使用线程资源导致服务器cpu切换高而浪费，是否可以用线程池。比如获取数据的策略导致增加网络开销，是否可以提前处理好（冗余在某种情况下也不是坏事）？比如说锁定过大的数据块导致效率低下，可否详细分析具体上锁的粒度？比如说是否可以在允许的情况下使用nolock，行锁？

四.性能调优

1. 对于性能问题的出现，如果不是经验相当丰富的资深开发，也会一时不知道如何处理。这时候需要和测试配合一步步发现和调整。
2. 具体调优的话可以参考定位的步骤：环境改善，配置调整，客户端是否瓶颈，节点服务使用方式，算法调优。需要在不断的调整之后就测试一轮，数据进行对比，多次迭代修改，测试数据验证。