响应时间

最近应用出现了一系列的性能问题，之前对性能不太关注，现在得恶补下基本知识了。先从常用的一些性能指标开始了解。 PV PV是 Page View的缩写。用户通过浏览器访问页面，对应用服务器产生的每一次请求， 记为一个 PV。 PV的统计一般可以通过监控埋点或者统计访问日志统计得出， 通过一些监控系统，也可以直观看到统计数据。 ResponseTime响应时间 响应时间(RT)是指从客户端发一个请求开始计时，到客户端接收到从服务器端返回的响应结果结束所经历的时间，响应时间由 请求发送时间、网络传输时间和服务器处理时间 三部分组成。 QPS/TPS QPS/TPS原本含义为：系统每秒能处理的请求/事务的数量，或者说吞吐量。在web应用是指web应用每秒能处理的request数量。这个是衡量系统性能的重要指标。 QPS（TPS）= 并发数/平均响应时间。 QPS的统计可以通过访问日志统计对应时间的PV量除以对应时间求得。在性能测试中可以通过工具测试获得。 一般经常统计的是高峰期PV对应的QPS LOAD负载 系统平均负载，被定义为在特定时间间隔内运行队列中的平均进程数。如果一个进程满 足以下条件则其就会位于运行队列中： -它没有在等待 I/O操作的结果 -它没有主动进入等待状态（也就是没有调用'wait'） -没有被停止（例如：等待终止）1 这个负载值比较理想的指标值是cpu个数*核数*0

一、为什么学习事务？ 需求： 1. 统计订票网站登录业务需要的具体时间； 2. 登录账户不是jojo，则登录业务失败； 问题：统计时间有很多办法可以做到，但如何把登录业务标记成功或失败呢？ 二、什么是事务？ 概念：事务（Transaction）是用户在应用软件上操作的一个业务或多种业务集合(actions)的统称； 作用： 1. 通过事务可标记业务开始和结束，并且可统计相应业务的操作时间(事务时间)【重点】 2. 通过事务状态机制，可判断相应业务执行的成功与失败；【了解】 3. 通过事务来衡量服务器性能； 三、添加事务 说明：LR添加事务有两种方式： 1). 录制脚本的时候添加【了解】 2). 运行脚本的时候添加【推荐】 3.1 添加事务-录制时添加【了解】 3.2 添加事务-运行脚本时添加【重点】 提示： 1. 插入事务开始 lr_start_transaction("Name") 1. 插入方式： 1). Ctrl+T 2). 鼠标右键Insert->Start Transaction 3). 工具栏菜单(Insert)->Start Transaction 2. 参数 Name:事务名称 2. 插入事务结束 lr_end_transaction("Name", "status") 1. 插入方式：参考插入事务开始 2. 参数 Name:事务名称和开始事务名相同； status

1、开启gzip请求 curl -I http://www.sina.com.cn/ -H Accept-Encoding:gzip,defalte 2、监控网页的响应时间 curl -o /dev/null -s -w "time_connect: %{time_connect}\ntime_starttransfer: %{time_starttransfer}\ntime_total: %{time_total}\n" "http://www.kklinux.com" 3. 监控站点可用性 curl -o /dev/null -s -w %{http_code} "http://www.kklinux.com" 4、以http1.0协议请求（默认为http1.1） curl -0 .............. 监控站点首页下载时间： curl -o /dev/null -s -w ‘%{ time_total }’ http://www.miotour.com curl -o /dev/null -s -w ‘%{ http_code }’ http://www.miotour.com curl -o /dev/null -s -w %{ http_code }:%{ time_connect }:%{ time_starttransfer }:%{ time_total }

性能指标监听 概述 性能测试过程中，想要得到比较靠谱的性能数据，就不得不对各种性能数据进行动态监听。jmeter中提供了很多性能数据的监听器，我们通过监听器可以来分析性能瓶颈 本文用吞吐量模式，演示200线程的负载测试结果来描述图表（压测百度） 常用监听器 Transactions per Second 监听动态TPS，用来分析吞吐量。其中横坐标是运行时间，纵坐标是TPS值。红色表示通过的TPS，绿色表示失败的。 可以看出在56s左右，tps达到最高点1000/s，之后开始直线下降。 Hits per Second 动态监听单位时间的点击率，也就是触发的请求数。其中横坐标是运行时间，纵坐标是HPS值。 可以看出在58s的时候点击率达到最大（996/s），之后直线下降 Response Times Over Time 监听整个事物运行期间的响应时间。其中横坐标是运行时间，纵坐标是响应时间（单位是毫秒） 响应时间在一分钟左右的时候开始急剧上升，此处就是响应时间的瓶颈 Active Threads Over Time 监听单位时间内活动的线程数。其中横坐标是单位时间（单位是毫秒），纵坐标是活动线程数（也就是并发数） Response Times Percentiles 监听响应时间分布的百分比。其中横坐标是请求数的百分比，纵坐标是响应时间。此图表示有90%的请求响应时间在92ms以内。

在使用top 命令的时候会看到这么一行： 翻译一下： us ：用户态使用的 cpu 时间比 sy ：系统态使用的 cpu 时间比 ni ：用做 nice 加权的进程分配的用户态 cpu 时间比 id ：空闲的 cpu 时间比 wa ： cpu 等待磁盘写入完成时间 hi ：硬中断消耗时间 si ：软中断消耗时间 st ：虚拟机偷取时间 如果一台机器看到 wa 特别高，那么一般说明是磁盘 IO 出现问题，可以使用 iostat 等命令继续进行详细分析。 1, 安装 iostat 　　 yum install sysstat 之后就可以使用 iostat 命令了， 2 ，入门使用 　　 iostat -d -k 2 参数 -d 表示，显示设备（磁盘）使用状态； -k 某些使用 block 为单位的列强制使用 Kilobytes 为单位； 2 表示，数据显示每隔 2 秒刷新一次。 tps ：该设备每秒的传输次数（ Indicate the number of transfers per second that were issued to the device. ）。 " 一次传输 " 意思是 " 一次 I/O 请求 " 。多个逻辑请求可能会被合并为 " 一次 I/O 请求 " 。 " 一次传输 " 请求的大小是未知的。 kB_read/s ：每秒从设备（ drive expressed

1.事务 从客户端发请的一个或多个请求（这些请求组成一个完整的操作（多个http请求）），到客户端接收到从服务器返回的响应。 2.TPS 每秒中系统能够处理的事务数；关联1理解 3.请求响应时间 从客户端发起的一个请求开始，到客户端收到从服务器返回的响应。整个过程所耗费的时间。 4.事务响应时间 事务可能由一个或多个请求组成的，事务响应时间主要是针对于用户的角度而言，主转账；关联1理解。 5.并发定义 没有严格意义上的并发。并发总有先后，无论差距是1毫秒或者1微秒，总有一个时间差。所以并发讲的是一个时间范围内，比如1秒内的请求。 6.并发用户数 同一单位时间内对系统发起请求的用户数量。 7.吞吐量 一次性能测试过程中网络上传输的数据量的总和。 8.吞吐率 单位时间内网络上传输的数据量； 吞吐率=吞吐量/传输时间； 9.点击率 每秒中用户向服务器提交的请求数。这个指标是web应用程序特有的一个指标，可以想象为每秒钟用户总共再页面上进行多少次点击动作，但是需要注意的是一次鼠标单击的操作后，客户多可能向服务器发送了多次请求。 10.资源使用率 对不同的系统资源的使用情况，如cpu、内存、io。 性能并不是随着服务器增加节点稳定递增性能的，也会有性能的损耗，所以测算出损耗也是性能工程师的任务 来源： CSDN 作者： 抽风同学 链接： https://blog.csdn.net

一、QPS/TPS QPS：Queries Per Second的缩写，意思是“每秒查询率”，是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。 TPS： Transactions Per Second的缩写，也就是事务数/秒（每秒处理的事务数）。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。 TPS即每秒处理事务数，包括了 用户请求服务器 服务器自己的内部处理 服务器返回给用户 这三个过程，每秒能够完成N个这三个过程，TPS也就是N； QPS基本类似于TPS （有时候也会把两者当成一个），但是不同的是，对于一个页面的一次访问，形成一个TPS；但一次页面请求，可能产生多次对服务器的请求，服务器对这些请求，就可计入“QPS”之中。 例如：访问一个页面会请求服务器3次，一次放，产生一个“T”，产生3个“Q” 二、系统吞吐量 一个系统的吞度量（承压能力）与request对CPU的消耗、外部接口、IO等等紧密关联。单个reqeust 对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高。 系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间 QPS（TPS）

测试需求： 测试20个用户访问www.baozhenart.com在负载达到30QPS时的平均响应时间 　　QPS：Query Per Second每秒查询率。是一台查询服务器每秒能够处理的查询次数。在因特网上，作为域名系统服务器的性能经常用每秒查询率来衡量。 测试步骤： 第一步：添加线程组 线程组主要包含三个参数：线程数、准备时长、循环次数 　　 线程数：虚拟用户数。一个虚拟用户占用一个进程或线程。设置多少虚拟用户数在这里就设置多少个线程数 准备时长（单位为s）:设置虚拟用户数需要多长时间全部启动。如果线程数为20，准备时长为10，则需要在10秒钟启动20个线程。也就是每秒钟启动2个线程。 循环次数：每个线程发送请求的次数。如果线程数为20，循环次数为5，那么每个线程发送5次请求。总请求数为20*5=100.如果勾选了"永远"，那么所有线程一直发送请求，一直到停止运行脚本 第二步：增加HTTP请求 一个HTTP请求有着许多的配置参数，下面详细介绍 协议：向目标服务器发送HTTP请求时的协议，可以是http或者https，默认为http。 方法：发送HTTP请求的方法，包括GET、POST、HEAD、PUT、DELETE等 Content encoding:内容的编码方式，默认值为iso8859 路径：目标URL路径（不包括服务器地址和端口） 自动重定向：如果选中该选项

基准测试 (Performance Benchmark Test) 概念 1)每次对外发布产品版本前必须要完成的测试类型 2)执行固定的性能测试场景得到系统的性能测试报告 3)与上一版本发布时的基准测试结果进行对比 4)优化 or 恶化 ? 测试目的 (1)获取系统性能基准作为参照物 (2)识别系统或环境的配置变更对性能带来的影响 (3)给系统优化前后的性能提升/下降提供参考标准 (4)观察系统的整体性能趋势与性能拐点，识别系统性能风险 基准评估 同一事务的响应时间变慢了 上一版本中，用户登录的响应时间是2s，在最新的被测版本中这个响应时间变成了4s； 系统资源的占用率变高了 上一版本中，平均 CPU 占用率是15%，在最新的被测版本中平均 CPU 占用率变成了 30%； 等等。。。。 负载测试 测试目的 1)持续稳定地增加系统的负载，测试系统性能的变化 2)找出指标阈值下的系统瓶颈和性能拐点 3)测试系统所能承受的最大负载量 4)找出内存管理错误，内存泄漏，缓冲区溢出的问题 5)找到处理极限，为调优提供数据 6)找出系统在稳定情况下的最大压力值 测试意义 通过改变负载方式、增加负载，发现系统中所存在的性能问题 实例 (1)200个并发用户访问时的最大响应时间，最大吞吐量 (2)21个小时内要处理 1000 笔业务，找到最大并发数 (3)响应时间不超过10s的最大负载 (4

负载均衡的基本算法，主要有以下几种（ 参考F5产品 ）： 随机：负载均衡方法随机的把负载分配到各个可用的服务器上，通过随机数生成算法选取一个服务器，然后把连接发送给它。虽然许多均衡产品都支持该算法，但是它的有效性一直受到质疑，除非把服务器的可运行时间看的很重。 轮询：轮询算法按顺序把每个新的连接请求分配给下一个服务器，最终把所有请求平分给所有的服务器。轮询算法在大多数情况下都工作的不错，但是如果负载均衡的设备在处理速度、连接速度和内存等方面不是完全均等，那么效果会更好。 加权轮询：该算法中，每个机器接受的连接数量是按权重比例分配的。这是对普通轮询算法的改进，比如你可以设定：第三台机器的处理能力是第一台机器的两倍，那么负载均衡器会把两倍的连接数量分配给第3台机器。 动态轮询：类似于加权轮询，但是，权重值基于对各个服务器的持续监控，并且不断更新。这是一个动态负载均衡算法，基于服务器的实时性能分析分配连接，比如每个节点的当前连接数或者节点的最快响应时间等。 最快算法：最快算法基于所有服务器中的最快响应时间分配连接。该算法在服务器跨不同网络的环境中特别有用。 最少连接：系统把新连接分配给当前连接数目最少的服务器。该算法在各个服务器运算能力基本相似的环境中非常有效。 观察算法：该算法同时利用最小连接算法和最快算法来实施负载均衡。服务器根据当前的连接数和响应时间得到一个分数