响应时间

章节一压力测试课程介绍 1、2018年亿级流量压测系列之Jmeter4.0课程介绍和效果演示 简介： 讲解课程安排，使用的Jmeter版本 讲课风格：涉及的组件，操作配置多，不会一次性讲解，会先讲部分，然后在后续操作中慢慢补充，更容易消化和理解 2、常用压力测试工具对比 简介：目前用的常用测试工具对比 1、loadrunner 性能稳定，压测结果及细粒度大，可以自定义脚本进行压测，但是太过于重大，功能比较繁多 2、apache ab(单接口压测最方便) 模拟多线程并发请求,ab命令对发出负载的计算机要求很低，既不会占用很多CPU，也不会占用太多的内存，但却会给目标服务器造成巨大的负载, 简单DDOS×××等 3、webbench webbench首先fork出多个子进程，每个子进程都循环做web访问测试。子进程把访问的结果通过pipe告诉父进程，父进程做最终的统计结果。 章节二 JMeter4.x基础知识讲解和压测实操 3、Jmeter基本介绍和使用场景 简介 1、压测不同的协议和应用 1) Web - HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, …) 2) SOAP / REST Webservices 3) FTP 4) Database via JDBC 5) LDAP 轻量目录访问协议 6) Message-oriented

1.响应时间（Response time） 　　　　 　　响应时间就是用户感受软件系统为其服务所耗费的时间，对于网站系统来说，响应时间就是从点击了一个页面计时开始，到这个页面完全在浏览器里展现计时结束的这一段时间间隔，看起来很简单，但其实在这段响应时间内，软件系统在幕后经过了一系列的处理工作，贯穿了整个系统节点。根据“管辖区域”不同，响应时间可以细分为： 　　（1）服务器端响应时间，这个时间指的是服务器完成交易请求执行的时间，不包括客户端到服务器端的反应（请求和耗费在网络上的通信时间），这个服务器端响应时间可以度量服务器的处理能力。 　　（2）网络响应时间，这是网络硬件传输交易请求和交易结果所耗费的时间。 　　（3）客户端响应时间，这是客户端在构建请求和展现交易结果时所耗费的时间，对于 普通的瘦客户端 Web 应用来说，这个时间很短，通常可以忽略不计；但是对于胖客户端 Web 应用来说，比如 Java applet、AJAX，由于客户端内嵌了大量的逻辑处理，耗费的时间有可 能很长，从而成为系统的瓶颈，这是要注意的一个地方。 那么客户感受的响应时间其实是等于客户端响应时间+服务器端响应时间+网络响应时 间。细分的目的是为了方便定位性能瓶颈出现在哪个节点上 2．吞吐量（Throughput） 　　吞吐量是我们常见的一个软件性能指标，对于软件系统来说，“吞”进去的是请求，“吐”

　　自网站诞生以来，响应速度/响应时间一直都是大家关心的话题，而速度慢乃是网站的一个杀手，正当大家以为四核和宽带能力的提升能够解决这些问题时，Wi-Fi和移动设备为热点移动互联网又悄然兴起。 　　在2006年，Amazon曾做过一个报道，响应时间每提高100ms，他们便会增加1%的收入。优化的价值已显而易见，但到底多快才是个标准，或者速度有多快才算够快呢？那么到底什么是响应时间，它有多大的价值？ 　　从技术上来讲，响应时间是指用户发送一个指令（例如，一个页面请求）浏览器接收到完成加载的时间。定义看起来非常简单，但当你在思考如何设计一个带有许多额外对象的现代网页时，响应时间对用户体验是非常重要的，并且它也不会告诉你，哪些因素影响着响应时间。 　　一个稍微好点的衡量标准则是页面加载时间。页面加载时间是指从用户发送指令到浏览器加载完整个页面对象所用的时间。好比响应时间，页面加载整个过程涉及到很多事情，它由一系列执行步骤组成，并且每一步都需要单独监控，每一步都会告诉你问题所在。 　　步骤包括： DNS解析时间 TCP链接时间 HTTP重定向时间 首字节加载时间 HTML内容时间 整个页面对象加载时间 　　 DNS解析时间 　　DNS查找的时间就是将域名翻译成具体IP的时间，大多人数认为，无论DNS是否工作，都不是件简单的事情。 　　在这个过程中，你可能会遇到许多微妙的问题，比如响应时间太长

性能测试监控关键指标说明： 　　①. 资源指标 　　CPU使用率：指用户进程与系统进程消耗的CPU时间百分比，长时间情况下，一般可接受上限不超过85%。 　　内存利用率：内存利用率=(1-空闲内存/总内存大小)*100%，一般至少有10%可用内存，内存使用率可接受上限为85%。 　　磁盘I/O: 磁盘主要用于存取数据，因此当说到IO操作的时候，就会存在两种相对应的操作，存数据的时候对应的是写IO操作，取数据的时候对应的是是读IO操作，一般使用% Disk Time(磁盘用于读写操作所占用的时间百分比)度量磁盘读写性能。 　　网络带宽：一般使用计数器Bytes Total/sec来度量，Bytes Total/sec表示为发送和接收字节的速率，包括帧字符在内。判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较。 　　②.系统指标 　　并发用户数：某一物理时刻同时向系统提交请求的用户数。 　　在线用户数：某段时间内访问系统的用户数，这些用户并不一定同时向系统提交请求。 　　平均响应时间：系统处理事务的响应时间的平均值。事务的响应时间是从客户端提交访问请求到客户端接收到服务器响应所消耗的时间。对于系统快速响应类页面，一般响应时间为3秒左右。 　　事务成功率：性能测试中，定义事务用于度量一个或者多个业务流程的性能指标，如用户登录、保存订单、提交订单操作均可定义为事务。 来源

在应用程序的生命周期中，应尽早建立性能测试意识。 确保应用一切就绪 需要考虑的问题： 应用程序部署后需要支持多少最终用户？6个月后？1年后？3年后呢？ 这些用户分布在哪里？他们是如何与系统建立连接的？ 部署后有多少在线用户、并发用户？6个月后？1年后？3年后呢？ 引申出的问题： 对于每个应用程序，需要多少台服务器？这些服务器的配置是怎么样？是否需要集群？ 我需要提供什么类型的网络基础设施？ 性能测试重点关注的方面： 选择合适的性能测试工具； 设计一个合适的性能测试环境； 设置切合实际的性能测试目标； 确保被测应用程序足够稳定； 安排有足够的时间进行有效的性能测试； 做到代码冻结； 确定和编写关键业务脚本； 提供高质量、足够的测试数据； 确保准确的性能测试设计； 确定监控服务器和网络的关键性指标（KPI）； 安排有足够的时间进行有效的性能测试。 性能测试工具 性能测试工具要求： 协议支持（通信协议）； 认证模式（License）； 概念验证（Proof of concept，简称POC，证明其可行性，示范其原理）； 脚本效果（生成脚本的编辑程度）； 解决方案与负载测试工具（提供解决方案）； 外包性能测试or内部执行。 注意：制定替代方案。 预留足够时间 安排足够的时间确保有效的性能测试。 需要考虑的几个方面： 准备测试环境的时间 准备负载生成器环境 确定及描述业务事务的时间

绪言A：前端性能的重要性 性能黄金法则：只有10%~20%的最终用户响应时间花在了下载HTML文档上，其余80%~90%时间花在了下载页面中的所有组件上。 规则1：减少HTTP请求 图片地图 图片地图允许在一个图片上关联多个URL，目标URL的选择取决于用户点击了图片上的哪个位置。 图片地图有两种类型 服务器端图片地图：将用户点击提交到服务端，并向其传递用户点击的x、y坐标。Web应用程序将x、y映射为适当的操作。 客户端图片地图：通过HTML的MAP标签实现。 CSS Sprites 任何支持背景图片的HTML元素都能CSS Sprites，通过background-image和background-position来实现。 内联图片 通过使用data:URL模式可以在Web页面中包含图片但无需任何额外的HTTP请求。 data:[<mediatype>][;base64],<data> 由于data:URL是内联在页面中的，在跨越不同页面时不会被缓存 合并脚本和样式表 规则2：使用内容发布网络（CDN） 如果应用程序Web服务器离用户更近，则一个HTTP请求响应时间将缩短。另一方面，如果组件Web服务器离用户更近，则多个HTTP请求的响应时间将缩短。 内容发布网络 内容发布网络是一组分布在多个不同地理位置的Web服务器，用于更加有效地向用户发布内容。 优点： 缩短响应时间

系统性能优化并不是一上来就是JVM优化，相反JVM优化几乎是最后的手段了。影响一个系统的性能的因素非常多，如图： 从服务本身来看，影响服务性能的主要包扣： 我们写代码时所选择的数据结构和算法 服务开启的线程时是否合理 WEB应用，WEB服务 JVM方面的影响 最后是操作系统的影响 从整个服务架构上来看还有： 数据持久化 服务间的远程调用 消息缓存等中间件的选择 常用的性能测试指标 响应时间 一个请求从提交到响应所耗费的时间，一般比较关注平均响应时间，和最大响应时间。 常用组件的响应时间： 操作|响应时间 ---|--- 打开一个站点 |几秒 数据库查询一条记录（有索引）| 十几毫秒 机械磁盘一次寻址定位| 4毫秒 从机械磁盘顺序读取1M数据 |2毫秒 从SSD磁盘顺序读取1M数据| 0.3毫秒 从远程分布式缓存Redis读取一个数据|0.5毫秒 从内存读取1M数据 |十几微妙 Java程序本地方法调用 |几微妙 网络传输2Kb数据 | 1微妙 从上述表格我们能看出： 数据持久化，使用SSD与使用机械硬盘相比性能可以提高将近10倍； 数据查询，数据如果直接在本地内存，那么它的读取效率比数据库快将近1000倍，比redis快30倍左右；如果数据在redis缓存，那么它的读取速度比数据库快30倍左右；这也是为什么使用缓存是提升系统性能的“银弹”的原因。 为监控而生的多级缓存框架

缓存是搭建高性能高并发系统的必备手段之一，通常用来解决性能瓶颈，是程序员的必备知识点，也是面试必备考点。 尽管，产品经理大概率不会关注系统性能，但程序员在实现需求的时候必须思考系统承载的并发量和用户量。缓存主要用来解决性能瓶颈的问题，一旦错误使用反而会令系统崩溃。今天，我们就通过4W的方式系统化地总结缓存相关的理论知识。 随着互联网业务的快速迭代以及用户量激增，应用架构需要不断调整甚至重构以适应这种业务的快速发展。当数据量迅速增长，业务逻辑越复杂，服务链路不断增加等等一系列问题，会导致RT过长，服务性能需要逐渐提升以满足更优的用户体验。在优化系统架构时通常的所用的两种方式scale up以及scale out，scale out就是通常所说的水平扩展，将应用服务设计成无状态性，可以方便水平扩展通过增加硬件的方式分解访问压力。而scale up则是将单个服务链路性能提升，以提升QPS以及系统的吞吐量。在追求更优的性能时，大多数业务场景是读多写少的情况，一般会通过引入缓存的方式解决。 What——什么是缓存? 关于缓存的定义，在wiki中为： a collection of data duplicating original values stored elsewhere on a computer, usually for easier access.

需要对服务器接口做压力测试前，要理解的一些术语含义：响应时间、并发、RPS 并发： 什么叫并发？并发不是我们理解的在loadrunner场景中设置并发数，而是正在系统中执行操作或者在系统的队列中排队的用户数，当然在lr的世界里，我们也会粗略的认为二者相等。 响应时间： 严格意义上说是从客户端发送请求开始，到客户端接受到服务器的返回结束。在我们测试环境中，客户端和被测服务器往往在一个机房一个网段甚至同一个交换机，所以我们通常把响应时间认为是服务器处理请求所耗费的实际。 RPS：每秒请求数，这里还有两个我们通常认为和RPS相等的名词，arrival rate、TPS。 根据little定律，我们知道以上三者有以下关系，在平衡状态，或者说到达速度,尚未达到应用处理的瓶颈的时候: 并发 = rps * 响应时间 来源： https://www.cnblogs.com/yokooo/p/12374088.html

一般在进行压力测试的时候，分单场景和混合场景。 单场景：即对单个接口进行压力测试 混合场景：在有业务流程的情况下，对多个接口进行压力测试 衡量系统性能好坏的指标： 1）TPS：服务端每秒钟处理的请求数，越大越好 2）响应时间：每个请求的处理时间，越小越好 3）并发用户数 一般场景压测的时间是10-15分钟，疲劳测试可以压一天或一周，以具体情况而定。 本文以获取学生信息为例进行 jmeter 压力测试演示。 1. 打开 jmeter 后，添加线程组。 右击“线程计划”，添加 → Theads(Users) → 线程组 我们先来设定有10个用户同时获取学生信息，看看服务器的性能如何。 线程数（即并发用户数）设置为10 勾选循环次数为永远 勾选调度器，持续时间设定为60秒 2. 添加 HTTP 请求。 右击“线程组”，添加 → Sampler → HTTP请求 输入服务器名称或 IP 输入路径 方法选择get 添加参数，获取一个叫“小黑”的学生信息 3. 添加查看结果树、聚合报告 1）右击“线程组”，添加 → 监听器 → 查看结果树 2）右击“线程组”，添加 → 监听器 → 聚合报告 查看结果树，可以查看每一个请求的运行情况。 聚合报告，统计请求数、TPS、响应时间等。 点击工具栏中的绿色小三角，开始运行，从下图中可以看到都是运行成功。 再来看看聚合报告 前面设置脚本：并发10线程