响应时间

前言 话说搞运维的人没有两把“刷子”，都不好意思上服务器操作。还好，我还不是搞运维的，我一直都自诩是开发人员，奈何现在的东家运维人员“水”的一比，还要我这个自诩是开发的人撸起袖子亲自上阵，好吧，没有办法，重拾以前的命令，再次走起~~~ 说到运维，那就离不开监控磁盘了。而说到磁盘监控，那又不得不说道说道 iostat 命令了。这篇文章就对那个我曾经非常熟悉的 iostat 命令进行详细的总结。 命令详解 Linux系统中的 iostat 是I/O statistics（输入/输出统计）的缩写， iostat 工具将对系统的磁盘操作活动进行监视。它的特点是汇报磁盘活动统计情况，同时也会汇报出CPU使用情况。同 vmstat 一样， iostat 也有一个弱点，就是它不能对某个进程进行深入分析，仅对系统的整体情况进行分析。 iostat 常用命令格式如下： iostat [参数] [时间] [次数] 命令参数说明如下： -c 显示CPU使用情况 -d 显示磁盘使用情况 -k 以K为单位显示 -m 以M为单位显示 -N 显示磁盘阵列(LVM) 信息 -n 显示NFS使用情况 -p 可以报告出每块磁盘的每个分区的使用情况 -t 显示终端和CPU的信息 -x 显示详细信息 下面就对我们常用的使用方式进行详细的总结。 使用实例 命令： iostat -x 说明：显示详细信息 输出： [user1

[问题发现] 使用 zabbix 软件监控服务器时发现 cpu 突然异常，在业务主机上使用 top 命令查看系统的整体运行情况，使用 t op 命令后发现 mysqld 占用 C PU特别高，初步判断可能是mysqld出现问题，需要排查： [排查步骤] Step1: 登录 oneapm ai 平台后可以看到应用列表的总览视图，在总览视图中可以看到所有应用的名称以及相关指标信息，同时我们还可以根据应用颜色变化来判断每个应用的指标变化情况。本例中在 Acmeair 应用的 “用户体验一览”选项卡下可以看到它的业务在最近一段时间内出现了 71 次失败，我们需要点击此应用查看详情，如图一： 图一 Step2 ： 利用 top 命令已经基本排查出是数据库导致 CPU占用过高，我们可以通过查看调用数据库的节点发现问题。 在 AI 平台上点击某个应用进入到该应用的主页，进入之后可以看到该应用的总体拓扑图，总览拓扑图会把应用中所有 Tier 、数据库、远程服务与其他应用之间的调用关系描绘出来，并且显示他们的性能情况。当某个节点的颜色为黄色或红色时，代表该 Tier 的健康状态是告警或严重。 点击拓扑图右上侧的 “数据库 - 展开”选项，可以看到调用 m ysql 数据库的节点，点击该节点（例如下图中的 Webapp11 节点），出现的弹框中有总览、节点、 Web 事务入口、 Web 事务

此文已由作者朱笑天授权网易云社区发布。 欢迎访问 网易云社区 ，了解更多网易技术产品运营经验。 问题的起因是笔者在一轮性能测试的中，发现某协议的响应时间很长，去观察哨兵监控里的javamethod监控可以看到以下结果： onMessage是该协议的总入口，可以看到该协议平均耗时为352.11ms，观察其他耗时方法可以看到updateUserForeignId耗时307.75ms，那么可以认为该方法的响应时间慢是该协议的最主要性能瓶颈，这时候我们应该看看该方法究竟做了哪些操作导致响应时间过长： 从哨兵监控中可以看到userStorage.updateUserForeignId方法耗时122.86ms，userStorage.updateForeignIdPegging方法耗时71.33ms，这两个方法有成为了SessionProcessHelper.updateUserForeignId方法的主要耗时点，基于对代码的熟悉程度xxxStroge方法都是一些数据库的操作，那么现在可以初步的认为数据库的相关操作可能是问题的根源所在，为了清楚的展示问题，我们先选择一个逻辑较简单的方法分析一下，从上面的哨兵方法监控里可以看到updateSession方法耗时34.88ms，查看该方法代码： 可以看到方法只是有一个简单的dao层的操作，通过查看dao层方法可知该方法仅仅是一个update操作

jmeter-思考时间 ：是用定时器做的，固定定时器，同一个作用域生效，3000ms 停了3秒才会运行， 高斯随机定时器：偏差1000 固定延迟：3000，上下浮动不会超过1秒，就是2秒到4秒之间的一个随机数 可以控制tps，可以控制单位时间内请求的个数，不加思考时间处理的请求的个数比较多，服务器处理能力没到极限； 如果服务器到了极限，不加思考时间，需要排队，加了思考时间，避免排队，可以控制响应时间以及tps jmeter-集合点 ：定时器里面的，为了让线程同时等待一块，模拟瞬时压力 Number of simulates to group by 10(xianchengshu<并发的线程数) timeout：2000 等到到2s还没有触发不等待了往下运行 jmeter-线程组 ： 线程数：10 就是10个并发 ramp-up period 1 在1秒内启动 循环次数：10 每个线程迭代1次 调度器配置： 使用调度器的时候需要勾选永远 持续时间：900s 测试时间900s,永远失效 启动延迟：10s,上面的1s失效 启动时间：持续时间失效 结束时间： jmeter-testplan测试计划 : 用户变量 uname 值 独立运行每个线程组 勾选后，线程组1运行完运行线程组2 jdbc脚本时：添加jar包 透传用户信息：没有返回session和token

web测试和app测试由于载体的不同，因此系统测试和细节也不尽相同 web测试是B/S架构的，基于浏览器的，app测试是C/S架构，必须有客户端，因此在系统测试时就会有区别 1.从系统架构上的区别 web测试只要更新了服务端，客户端就会同步进行更新，而且保证每一个用户的客户端的完全一致； app端不能保持完全一致，除非更新至同一版本 2.从性能上的区别 web端关注响应时间（一个请求从客户端发起，服务端做出回应返回至客户端的时间；响应时间=网络响应时间+应用程序响应时间），事务处理时间（服务端每秒处理的事务数，一个事务是指客户端向服务端发送请求然后服务端做出反应的过程），并发用户数（同一时刻与服务端交互的在线用户数量，用吞吐率衡量，吞吐率=吞吐量/传输时间），资源占用率（cpu利用率，资源占用率） app端关注流量，电量，cpu，gpu，memory 3.兼容性 web基于浏览器，一般选择不同浏览器内核的进行测试（ie,firefox,chrome） app依赖于手机或平板，不仅要看屏幕尺寸，分辨率，还要看设备系统 由于载体不同app测试会有专项测试 1.健壮性测试 异常场景和弱网测试 异常场景：中断，来电，短信，关机，重启等 中断测试有人为中断、新任务中断以及意外中断等几种情况，主要从以下几个方面进行验证： a.来电中断：呼叫挂断、被呼叫挂断、通话挂断、通话被挂断 b.短信中断

我们在对联机交易业务流程系统进行压力测试版本上线前压力测试时，一般先录制维护好脚本，设置好压测脚本场景，然后在进行压测，在对不同的业务流和各类涉及需要测试的功能交易进行压力测试，为了确保每个交易测试性能数据的准确性，不受前一次交易压测导致JVM内存使用问题导致影响本次交易测试，我们会对不同交易每次压测做好内存回收到基线上，性能测试过程中有时为了确保每次压测性能指标不受上次躁数干扰，我们会进行重启或者通过weblogic触发GC强制回收方式在进行压测，例如如下某系统压力实施工作流程： 一、启动应用管理服务器 ps –ef|grep java----查看系统运行的当前java实例进程 kill -9 PID sh start_app.sh -----进行实例重启 二、启动工作流管理服务器 ps –ef|grep java -----查看系统运行的工作流java进程 kill -9 PID sh start_wls.sh ----进行实例重启 三、开始压测 如 https://blog.51cto.com/372550/2444645，内容进行脚本开发和场景设计与实施 ； 四、监控 链接数据库服务器，使用top命令数据库服务器使用资源如下： 观察15分钟左右，截图。如果CPU不高于70%，则数据库服务器资源使用情况正常。如果数据库服务器的CPU高于70%，则抓取语法

概述 jmeter中提供了很多性能数据的监听器，我们通过监听器可以来分析性能瓶颈 本文以500线程的阶梯加压测试结果来描述图表。 常用监听器 1：Transactions per Second 监听动态TPS，用来分析吞吐量。其中横坐标是运行时间，纵坐标是TPS值。红色表示通过的TPS，绿色表示失败的。 最大TPS大约在140左右，从1分26秒左右，开始有未通过的事物 2：Hits per Second 动态监听单位时间的点击率，也就是触发的请求数。其中横坐标是运行时间，纵坐标是HPS值。 点击率波动较大，且不能持续上升。说明性能很不稳定 3：Response Times Over Time 监听整个事物运行期间的响应时间。其中横坐标是运行时间，纵坐标是响应时间（单位是毫秒） 响应时间在4950ms左右开始稳定下来，后续又经历一次大的波动 4：Response Times vs Threads 线程活动期间的响应时间监听。其中横坐标是活动的线程数（也就是并发数），纵坐标是响应时间（单位是毫秒） 5： Active Threads Over Time 监听单位时间内活动的线程数。其中横坐标是单位时间（单位是毫秒），纵坐标是活动线程数（也就是并发数） 6：Response Times Percentiles 监听响应时间分布的百分比。其中横坐标是请求数的百分比，纵坐标是响应时间

某月黑风高之夜，某打车平台上线了一大波（G+）优惠活动，众人纷纷下单。于是乎，该打车平台使用的智能提示服务扛不住直接趴窝了（如下图）。事后，负责智能提示服务开发和运维的有关部门开会后决定：必须对智能提示服务进行一次全面深入的性能摸底，立刻！现在！马上！ 那么一大坨问题就迎面而来：对于智能提示这样的后台服务，性能测试过程中应该关心那些指标？这些指标代表什么含义？这些指标的通过标准是什么？下面将为您一一解答。 概述 不同人群关注的性能指标各有侧重。后台服务接口的调用者一般只关心吞吐量、响应时间等外部指标。后台服务的所有者不仅仅关注外部指标，还会关注CPU、内存、负载等内部指标。 拿某打车平台来说，它所关心的是智能提示的外部指标能不能抗住因大波优惠所导致的流量激增。而对于智能提示服务的开发、运维、测试人员，不仅仅关注外部指标，还会关注CPU、内存、IO等内部指标，以及部署方式、服务器软硬件配置等运维相关事项。 外部指标 从外部看，性能测试主要关注如下三个指标 吞吐量：每秒钟系统能够处理的请求数、任务数。 响应时间：服务处理一个请求或一个任务的耗时。 错误率：一批请求中结果出错的请求所占比例。 响应时间的指标取决于具体的服务。如智能提示一类的服务，返回的数据有效周期短（用户多输入一个字母就需要重新请求），对实时性要求比较高，响应时间的上限一般在100ms以内。而导航一类的服务

性能测试指标：TPS，吞吐量，并发数，响应时间 常用的网站性能测试指标有：TPS、吞吐量、并发数、响应时间、性能计数器等。 并发数 并发数是指系统同时能处理的请求数量，这个也是反应了系统的负载能力。 响应时间 响应时间是一个系统最重要的指标之一，它的数值大小直接反应了系统的快慢。响应时间是指执行一个请求从开始到最后收到响应数据所花费的总体时间。 吞吐量 吞吐量是指单位时间内 系统能处理的请求数量 ，体现系统处理请求的能力，这是目前最常用的性能测试指标。 QPS（每秒查询数）、TPS（每秒事务数） 是吞吐量的常用量化指标 ，另外还有HPS（每秒HTTP请求数）。 跟吞吐量有关的几个重要是：并发数、响应时间。 QPS（TPS），并发数、响应时间它们三者之间的关系是： QPS（TPS）= 并发数/平均响应时间 性能计数器 性能计数器是描述服务器或操作系统性能的一些数据指标，如使用内存数、进程时间，在性能测试中发挥着“监控和分析”的作用，尤其是在分析统统可扩展性、进行新能瓶颈定位时有着非常关键的作用。 Linux中可以使用 top 或者 uptime 命令看到当前系统的负载及资源利用率情况。 资源利用率：指系统各种资源的使用情况，如cpu占用率为68%，内存占用率为55%，一般使用“资源实际使用/总的资源可用量”形成资源利用率。 $ top top - 15:47:21 up 4 days

负载均衡，满足高可用,即HA, (High Available) 硬负载 --> H5,Array等 软负载 轮询: 作为非常经典的负载均衡策略，早期该策略应用地非常广泛。其原理很简单，给每个请求标记一个序号，然后将请求依次派发到服务器节点中，适用于集群中各个节点提供服务能力等同且无状态的场景。其缺点也非常明显，该策略将节点视为等同，与实际中复杂的环境不符。加权轮询为轮询的一个改进策略，每个节点会有权重属性，但是因为权重的设置难以做到随实际情况变化，仍有一定的不足 随机: 与轮询相似，只是不需要对每个请求进行编号，每次随机取一个。同样地，该策略也将后端的每个节点是为等同的。另外同样也有改进的加权随机的算法，不再赘述 最小响应时间: 通过记录每次请求所需的时间，得出每台服务器的平均的响应时间，然后根据响应时间选择出最小的响应时间的服务器该策略能较好地反应服务器的状态，但是由于是平均响应时间的关系，时间上有些滞后，无法满足快速响应的要求。因此在此基础之上，会有一些改进版本的策略，如只计算最近若干次的平均时间的策略等 最小并发数: 记录了当前时刻，每个备选节点正在处理的事务数，然后选择并发数最小的节点。该策略能够快速地反应服务器的当前状况，较为合理地将负责分配均匀，适用于对当前系统负载较为敏感的场景 哈希 来源： https://blog.csdn.net/xuanyuanjiaqi