个人资料：
我开始用CSDN记录自己关于绩效测试的学习笔记和经验。 这本性能测试书我已经看完了，开始整理并记录里面的重要知识和实践经验。 因为自己记忆力不好，所以总是忘记。
感谢本书的作者。 前人种树，后人乘凉！
第一章性能测试、分析和调优基础1.1性能测试基础性能的理解
宏：系统稳定运行，高并发速度，不出现停机，系统处理用户请求所需的时间，系统可同时支持的高并发行数，以及系统每秒可处理的事务数
微观：每个事务的资源开销。 资源包括CPU、磁盘I/O、内存、网络传输等。 另外，服务器连接数、线程数、JVM Heap、内存分配和回收是否及时、缓存命中率
不同小组对性能的理解有很大不同
测试工程师：综合以上三种不同角色对性能的理解，全面考虑软件性能
1.1.1性能测试分类性能测试负荷测试压力测试标准测试稳定性测试扩展性测试可靠性测试等，
分类原则因测试目的而异，重点不同，但测试方法基本相同，就是给系统带来大量的访问压力
1.1.2性能测试场景业务场景：指系统的业务处理场景，描述具体的用户行为。 通过用户行为分析，划分不同的业务场景是性能测试时场景设计的重要来源——测试场景。 对于业务场景的实际仿真，测试场景的设计应尽量接近实际业务场景，有时需要根据测试条件进行脚本调整。 使情景模拟的情景尽可能接近现实的单一情景。 只针对单个业务流程的测试方案旨在测试系统的单个业务处理能力是否达到预期，并获得系统资源利用率正常情况下的最大TPS、平均响应时间等性能指标的混合方案。 测试方案包括多个业务流程，各业务流程按不同比重混合，尽量满足实际业务需要，评估混合业务处理能力是否符合预期。 评价系统混合业务处理容量为多少的1.2一般性能测试指标1.2.1响应时间要求或某项操作发出后到从服务器接收响应的时间之差即为响应时间，在性能测试中一般统计事务的响应时间
下图显示了HTTP请求可能通过的处理路径和节点
响应时间通常是网络时间APP的处理时间
1.2.2TPS/QPS事务是定制操作或一组操作的集合
TPS是TransactionPerSecond的缩写，是系统每秒可以处理的事务和事务数，通常统计每秒可以处理的事务数
QS是Query Per Second的缩写，它是衡量特定查询服务器在规定时间内处理流量的标准
1.2.3同时用户数用户思考时间：每个用户相邻操作都有一定的时间间隔，被定义为用户思考时间
绝对并发用户数：在某个时间点同时向服务器发送请求的并发用户数(服务器并发数) )。
相对并发用户数：在一段时间内向服务发出请求的并发用户总数(业务并发数) )。
系统中的并发用户数：当系统资源使用率达到允许的最大值时，可以同时承载的成功使用系统功能的用户总数
1.2.4PV/UV PV :页面浏览次数和点击次数。 每次用户访问系统或站点上的任何页面时都会被记录。 如果用户多次访问同一页面，则会累积访问次数。 PV是衡量一个电子商务网站性能和容量的重要指标，PV统计可分为全天PV、每小时PV和PV峰值
UV )指系统的独立访问者。 访问系统站点的终端之一称为访问者，记录每天的访问量。 同一客户端将被记录一次，并统计系统中有多少用户。 UV时，可以全天记录每小时的值
PV和UV是衡量网站非常重要的两个指标。
1.2.5点击率将每秒的页数称为点击率，反映了客户端每秒向服务器提交的请求数。 通常，一个hit通过动态请求来应对一个http请求。
1.2.6吞吐量是指系统在单位时间内处理的客户端请求的数量，可以用请求数/s、页数/s、字节数/s来表示，同时吞吐量与服务器CPU、内存、带宽IO等资源紧密相连
1.3性能测试目标是了解系统各项性能指标，通过性能测试发现系统承受多大并发访问量、系统平均响应时间多久、系统TPS多久等系统存在的性能问题。 常见的性能问题如下。 系统是否存在负载不均的情况，同时各服务器同时压力不均的系统是否存在内存泄漏，内存泄漏是指每次执行APP码时，内存使用量在不主动释放内存资源的情况下持续增加，最终导致服务器内存泄漏程序的执行逐渐变慢，最终因无法申请内存而结束执行，从而难以发现内存泄漏，需要在高并发条件下执行。 需要观察内存是否在持续增加。 系统是否存在连接泄漏问题。 连接泄漏的种类非常广泛，有数据库连接泄漏、HTTP连接泄漏或TCP/UDP连接泄漏。 除非系统实际上需要建立长连接，否则短连接一般需要在使用完毕后关闭并释放。 系统是否存在线程安全问题。 线程安全问题是并发访问较多的多线程处理系统中经常出现的问题，当系统存在线程安全问题时，多个线程会相继更改数据，得到的数据都将成为脏数据，是一个严重的系统系统上有死锁、死锁吗
问题也是多线程系统中经常会遇到的一个经典问题，一般常见的有系统死锁和数据库死锁；系统中是否存在网络架构或者应用架构扩展性问题，扩展性问题是指在性能指标无法满足的情况下，通过横向或者纵向扩展硬件资源后， 系统性能无法按照一定的线程规律快速递增。发现系统中的性能瓶颈，优化系统的性能；解决性能压测中存在的问题和性能瓶颈，通过不断的性能调优，使得系统可以满足预期的性能指标。1.4 性能测试的基本流程性能测试的基本流程：
1.4.1 性能需求分析 熟悉被压测系统的基本业务流程，明确此次性能测试要达到的目标，需要与产品经理、业务人员、架构师、技术经理一起沟通，找到业务的性能点。熟悉系统的应用架构、技术架构、数据架构、部署架构等，找到被测系统与其他系统的交互流程，明确被测对象的软硬件配置信息，集群部署方案，组网结构等，一般包括如下信息用户发起请求的顺序，请求之间的相互调用关系，异步响应还是同步响应，交互方式是http还是消息中间件业务数据流向，数据是如何流转的，经过了那些应用服务器，经过了那些存储服务评估被测试系统可能存在的重点资源消耗，是I/O 消耗型、CPU消耗型、还是内存消耗型，这样在压测时重点进行监控。关注部署架构，如果是集群部署，压测时要关注应用的负载分布是否均匀，每台服务器的资源消耗是否大致相同，单台服务器挂了，是否影响业务；明确应用的并发架构师多线程处理还是多进程处理，重点关注是否会死锁，数据是否存在不一致、线程同步锁是否合理，锁的粒度不易过大，过大会影响线程的并发处理明确系统上线后可能达到的最大并发用户数，用户期望的平均响应时间以及峰值时的业务吞吐量，并将这些信息转化为性能需求指标1.4.2 制定性能测试计划性能测试计划是性能测试活动的依据，在制定测试计划时要明确系统的上线时间点，当前项目的状态，可调配的硬件资源和测试人力资源，
性能测试计划的目的 : 性能测试环境的搭建，测试策略的选取，性能测试的任务与进度跟踪，性能测试的风险分析，性能测试的目标和明确性能测试完成的退出条件
性能测试的环境搭建 ： 明确性能测试的服务器类型，服务器内存和CPU，数据库类型和数据库大小，消息中间件，依赖的第三方服务等，整套性能测试环境的准备，明确由谁何时开始搭建测试环境，何时结束搭建测试环境。明确各个阶段具体的执行时间点和对应的责任人 性能测试风险和控制： 评估可能存在的风险和不可控因素，以及这些风险和因素对性能测试产生的影响，这对风险提前采取解决措施，规避风险，风险一般包括如下性能测试环境因素 ： 无法预期完成性能测试环境的搭建， 这中间可能有多种原因，硬件原因一般可能是性能压测服务器无法按时到位，服务器硬件配置无法满足预期，一般要求性能压测服务器硬件配置(使用同一个linux镜像)等同于生产环境，服务器节点数可以少于生产环境，但是需要保证每个测试应用服务至少部署了两台节点服务器，而且组网与生产环境组网相同，软件原因可能包括性能测试测试环境的软件配置无法和生产环境保持一致，一般要求性能测试环境软件配置，数据库配置，中间件配置等要和生产环境保持一致性能测试人力资源 ：性能测试人员无法按时到位参与项目的性能测试，这样的风险需要及时向项目经理或者人力资源求助协调合适的人员，这是非常重要的风险性能测试结果无法达到预期 ： 系统的性能无法达到生产预期的上线要求或者存在性能问题无法解决，这种情况大部分都是以业务为主，性能调优是一个长期的过程，此时可能考虑扩充服务器能否解决，如果无法解决需要提前上报风险。1.4.3 编写性能测试方案性能测试方案，按照什么样的思路和策略去测试，需要设计那些测试场景以及测试场景的先后执行顺序，每个测试场景需要关注的性能点等
明确硬件配置和软件配置
硬件配置 ：服务器CPU配置，内存配置，硬盘配置，集群环境，负载均衡配置，Nginx配置，组网配置等操作系统配置 ：操作系统版本，操作系统的参数配置保持与线上系统相同被测应用配置： Java的JVM配置和tomcat的配置，消息中间件配置，数据库配置，业务开关的配置保持与线上环境一致网络带宽配置 ： 一般为了排除网络瓶颈，除非有特殊要求，通常建议在局域网下进行测试，并且明确压测服务器的网卡类型以及网络交换机的类型，在比较大的压力下，网络也很有可能成为性能瓶颈(音视频媒体服务)，测试方案设计
测试场景设计 ：单一场景设计： 单一业务流程的处理模式设 ； 混合场景设计：多个业务流程同时混合处理模式的设计定义事务 ： 明确定义好压测事务，方便分析响应时间，混合场景可能是多个连续操作，按照事务维度分析响应时间和TPS明确监控对象 ： 针对不同场景和不同事务，分析可能的性能瓶颈点，需要监控的对象，比如TPS，平均响应时间，点击率， 并发连接数，CPU，内存，IO等。定义测试策略 ： 需要那种类型的性能测试，比如负载测试，压力测试，稳定性测试等，压力测试的加压方式等，明确性能测试场景的执行顺序 ： 一般先执行单场景，后执行混合场景测试。性能测试工具的选取
性能测试工具的选取，首先要明确待压测系统使用的协议，一般网络请求是Http协议， 实际工作中有可能不是http协议，比如视频的rtmp协议，hls协议等理解每种工具的实现原理，那些工具适合同步请求压测，那些工具适合用于异步请求压测，明确测试工具的加压方式；1.4.4 编写性能测试案例性能测试案例是对性能测试方案的细化，明确准备内容和细化操作方式
预置条件 ： 一般指执行此案例需要提前准备的条件，比如用户数据数据准备，性能测试其他必须数据，一般测试场景都需要提前准备数据执行步骤 : 详细的执行步骤，要说明每一个步骤需要执行的操作，脚本如何执行，如何加压，每次加压多少，加压保持多久，需要观察的指标和记录那些性能指标；性能检查点 ： 需要确认业务是否100%完成， 根据实际业务的检查点详细检查是否业务逻辑处理正常。在业务满足的情况下分析，性能要求是否达到了预期的要求1.4.5 性能调优如果测试结果没有达到预期要求，需要分析性能阻塞在哪里，性能优化，再次进行性能测试，最终达到性能要求。