tps

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

业务预估每日在线审批交易量10w笔预估，使用二八原则推算，80%的业务量发生在20%的业务时间（10小时）内，峰值TPS = 10w * 80% / (10 * 0.2 * 3600)，约11.11笔/秒。 根据业务量计算是一方面，还需要考虑上下游关联系统，如果上游系统TPS较大，则估算系统处理能力时应考虑到上游的访问量。如果下游TPS较小，应有隔离措施，避免下游系统受影响。 来源： https://blog.csdn.net/starryheavens/article/details/100030964

QPS、TPS、PV、UV、GMV、IP、RPS QPS Queries Per Second，每秒查询数。 每秒能够响应的查询次数 。 QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。每秒的响应请求数，也即是最大吞吐能力。 TPS Transactions Per Second 的缩写， 每秒处理的事务数目 。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。 客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数，最终利用这些信息作出的评估分。 TPS 的过程包括：客户端请求服务端、服务端内部处理、服务端返回客户端。例如，访问一个 Index 页面会请求服务器 3 次，包括一次 html，一次 css，一次 js，那么访问这一个页面就会产生一个“T”，产生三个“Q”。 PV （page view）即 页面浏览量 ，通常是衡量一个网络新闻频道或网站甚至一条网络新闻的主要指标。户每一次对网站中的每个页面访问均被记录 1 次。用户对同一页面的多次刷新，访问量累计。根据这个特性，刷网站的 PV 就很好刷了。 与 PV 相关的还有 RV ，即 重复访问者数量 （repeat visitors）。 UV 访问数（Unique Visitor）指

常见的互联网架构中，一般都能看到spring+mybatis+mysql+redis搭配的身影，在我所服务的公司亦是如此。一般来说，应用内部的接口都是直接调用的，所谓的面向接口编程，应用间的调用直接调或者通过类似dubbo之类的服务框架来执行，数据格式往往采用json，即统一也方便各数据间做转换和取值，缓存一般使用redis或memcached，存储一些对象或json格式的字符串。对外提供的接口，一般都需要进行压力测试，以便估算其性能，并为后续的调优提供指导方向，以下接口便是在压测过程中出现的各种“奇怪现象”，所谓奇怪，指的是从表象上看与我们正常的逻辑思路不符，但其本质还是我们对压力下程序的表现出来的特征不熟悉，用惯用的知识结构试图去解释，这根本是行不通的。下文是我在一次全面压测过程后对数据进行的分析汇总，其中的现象是很多压测常见的，里面的分析过程及改进措施我认为有很大的参考意义。具体内容如下：（部分接口为了安全我省略了其名称，但不影响我们的分析，另外形如1N3T之类的表示的是1台nginx，3台tomcat,具体的tps数值只是为了说明优化前后的比照，没有实际意义） 1 接口名称: 获取列表 1.1 压测现象:单台tps700多，应用cpu高负载 　　1.1.1 问题分析: 　　　　旧框架，平均响应时间长，应用CPU高，程序内部有大量的bean到map到json之间的转换

1.jp@gc - Transactions per Second TPS实时图：必看图，压测过程tps的波动情况 2.jp@gc - Response Times Over Time RT实时图：必看图，压测过程响应时间的波动情况，同TPS（RT响应时间增大时，TPS会下降） 来源： CSDN 作者： 米雪唲2 链接： https://blog.csdn.net/u014150715/article/details/103242490

1.背景 最近看了 阿里巴巴中间 件写的一篇文章，讲述了关于并发，RPS，RT之间的关系。感觉收获颇丰。自己使用JMeter工具对公式进行了验证。 2.验证 我们先来看几个基础知识定义： TPS：每秒完成的事务数。 QPS：每秒发送的请求数（同RPS）。 RT:交易响应时间。 VU虚拟用户数（VU是LR中的叫法，对应JMeter里的线程数） 针对以上术语定义，相信大家早已耳濡目染。 唯一需要强调的是TPS（可以包含1到N个请求） ，本文均以一个请求来进行测试验证。 Little定律公式：并发用户数 = QPS x RT 测试脚本结构图： 说明：JMeter版本5.1.1,采用JMeter自带Java请求（JavaTest），将Sleep_Time设置为1。 线程组设为100并发，运行10秒中，测试结果如下： 套用公式：并发数=701.3291634089131 x 0.133 = 93.276778679 ,与预期并发数（100）相差较大。初步怀疑是样本数太少，导致偏差较大。 线程组设为100并发，运行30秒中，测试结果如下： 套用公式：并发数=752.193926548995 x 0.129 = 97.033016524692 ,与预期并发数（100）还是有点差距。初步验证怀疑是正确的。 线程组设为100并发，运行180秒中，测试结果如下： 套用公式：并发数=789

软件性能术语 软件性能的主要术语 用户数 注册用户数（系统用户数） 在线用户 并发用户 虚拟用户 事务（TPS） 响应时间 QPS PV（Page View） 思考时间 吞吐量（一般指字节） 吞吐率（一般指字节） 性能计数器 软件性能非主要术语 集合点 迭代 步调 每秒连接数 软件性能的主要术语 用户数 有时会看到下面这样的描述：一个系统注册用户达到6000万人，其中每小时的活跃用户大概在60万人左右。这段描述介绍了两个信息，第一个信息：6000万人指的是注册用户，第二个信息：60万人指的是真实在线用户。 注册用户数（系统用户数） 注册用户是存在于系统数据库表中的基础数据。这部分用户是指系统所拥有的所有用户群体。这些用户是不会全部对系统造成压力的，唯一的压力就是这些用户占用了系统的存储，影响了数据库的容量。 在线用户 在线用户是真实产生压力的用户，这些用户是压力的根源，也就是系统要能够支持这么多人同时在线业务。 同时在线用户数：在一定的时间范围内，最大的同时在线用户数量 同时在线用户数=每秒请求数RPS（吞吐量）+并发连接数+平均用户思考时间 并发用户 在线用户是真实的用户，但不是所有的在线用户都会在系统上操作，可能有些用户在浏览网页、有些用户在做业务、有些用户只是开着浏览器。这时在线用户对系统产生压力的用户只有一部分，而这部分用户就是在线用户中的有效并发用户。

〇、经验总结 1.如果总的CPU占用率偏高，且基本都被业务线程占用时，CPU占用率过高的原因跟JVM参数大小没有直接关系，而跟具体的业务逻辑有关。 2.当设置JVM堆内存偏小时，GC频繁会导致业务线程停顿增多，TPS下降，最后CPU占用率也低了； 3.当设置JVM堆内存偏大时，GC次数下降，TPS上升，CPU占用率立刻上升。 4.Dom4J 这个xml解析工具性能很强大，但在处理节点和层级都较多的xml文本时，整体解析效率依然会成为业务处理瓶颈。 一、背景说明 最近新项目上线，需要对项目中的一个HTTP接口进行压力测试，以保证接口性能稳定性。该接口涉及到的主要业务是接收HTTP请求，获取请求中的xml报文参数，并将xml报文解析后存入MySQL数据库。接口业务流程如下： 该业务接口部署的服务器配置和部署MySQL组件的服务器配置一致，都是4核8G，50G普通硬盘，并且处于同一个内网网段，我们预估的性能指标要达到200并发，500TPS。 在压力测试过程中，我们重点关注TPS、GC次数、CPU占用率和接口响应时间等指标。 二、测试过程 完成项目部署后，我们开始编辑jemeter测试脚本，设置压力测试的标准为200个并发线程，在10秒内全部启动，持续压测时间15分钟，接着开始启动jemeter脚本进行测试。 1、第一次压力测试 （1）JVM配置 垃圾收集策略包括