qps

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

TPS是指每秒处理事务的个数，处理的载体可以是单台服务器，也可以是一个服务器集群。 例如：下单接口，一秒内，下单完成次数为1000，则下单接口总 tps = 1000，共有10台服务器提供下单服务，单台服务器的TPS = 1000/10。 QPS是指每秒查询的次数 例如：一个页面包含了服务器3次请求，一秒内，请求页面次数为1000，则该页面总 QPS = 3*1000 ，共有10台服务器提供页面查询服务，单台服务器的 QPS = 3*1000/10。 GMV = 销售额 + 取消订单金额 + 拒收订单金额 + 退货订单金额，即GMV为已付款订单和未付款订单两者之和。 来源： https://www.cnblogs.com/baokang/p/11421542.html

作者javadoop，资深Java工程师。本文已获作者授权发布。 原文链接https://www.javadoop.com/post/rate-limiter 本文主要介绍关于流控的两部分内容。 第一部分介绍 Guava 中 RateLimiter 的源码，包括它的两种模式，目前网上大部分文章只分析简单的 SmoothBursty 模式，而没有分析带有预热的 SmoothWarmingUp。 第二部分介绍 Sentinel 中流控的实现，本文不要求读者了解 Sentinel，这部分内容和 Sentinel 耦合很低，所以读者不需要有阅读压力。 Sentinel 中流控设计是参考 Guava RateLimiter 的，所以阅读第二部分内容，需要有第一部分内容的背景。 Guava RateLimiter RateLimiter 基于漏桶算法，但它参考了令牌桶算法，这里不讨论流控算法，请自行查找资料。 RateLimiter 使用介绍 RateLimiter 的接口非常简单，它有两个静态方法用来实例化，实例化以后，我们只需要关心 acquire 就行了，甚至都没有 release 操作。 // RateLimiter 接口列表： // 实例化的两种方式： public static RateLimiter create(double permitsPerSecond){} public

扛住100亿次请求？我们来试一试 XiaoJIaQI edited this page on 22 Feb 2017 · 15 revisions 扛住100亿次请求？我们来试一试 作者：ppmsn2005#gmail.com 项目: https://github.com/xiaojiaqi/10billionhongbaos wiki: https://github.com/xiaojiaqi/10billionhongbaos/wiki/扛住100亿次请求？我们来试一试 1. 前言   前几天，偶然看到了 《扛住100亿次请求——如何做一个“有把握”的春晚红包系统”》（[url](http://www.infoq.com/cn/presentations/how-to-build-a-spring-festival-bonus-system)）一文，看完以后，感慨良多，收益很多。正所谓他山之石，可以攻玉，虽然此文发表于2015年,我看到时已经是2016年末，但是其中的思想仍然是可以为很多后端设计借鉴，。同时作为一个工程师，看完以后又会思考，学习了这样的文章以后，是否能给自己的工作带来一些实际的经验呢？所谓纸上得来终觉浅，绝知此事要躬行，能否自己实践一下100亿次红包请求呢？否则读完以后脑子里能剩下的东西 不过就是100亿 1400万QPS整流 这样的字眼

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）指

转发：https://blog.csdn.net/beihenanfei/article/details/78919682 #高并发架构相关概念# 并发： 在操作系统中，是指一个时间段中有几个程序都处于已启动运行到运行完毕之间，且这几个程序都是在同一个处理机上运行，但任意一个时刻上只有一个程序在处理机上运行。 我们说的高并发是什么？ 上面的定义明显不是我们通常所言的并发，在互联网时代，所讲的并发、高并发，通常是指并发访问。也就是在某个时间点，有多少个访问同时到来通常如果一个系统的日PV在千万以上，有可能是一个高并发的系统，但是有的公司完全不走技术路线，全靠机器堆，这不在我们的讨论范围。 高并发的问题，我们具体该关心什么？ QPS：每秒钟请求或者查询的数量，在互联网领域，指每秒响应请求数(指HTTP请求) 吞吐量：单位时间内处理的请求数量(通常由QPS与并发数决定) 响应时间：从请求发出到收到响应花费的时间，例如系统处理一个HTTP请求需要100ms，这个100ms就是系统的响应时间 PV：综合浏览量(Page View)，即页面浏览量或者点击量，一个访客在24小时内访问的页面数量，同一个人浏览你的网站同一页面，只记作一次PV UV：独立访问(UniQue Visitor)，即一定时间范围内相同访客多次访问网站，只计算为1个独立访客 带宽：计算带宽大小需关注两个指标

TiDB 压力测试报告 （转载自公众号DBATech） 一、测试环境 1、tidb 集群架构： 测试使用最基本的TiDB架构。即 3个tidb-server节点+ 3个tikv节点 + 3个pd节点。 2、tidb集群的部署环境(混合部署)： 192.168.xx.A 1*server +1*PD +1*tikv 192.168.xx.B 1*server +1*PD +1*tikv 192.168.xx.C 1*server +1*PD+1*tikv IDC机器环境： 0S ：CentOS7 CPU ：Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz *24 RAM ：48GB DISK ：SSD, 480GB RAID0 TiDB 重要配置参数 以下这些参数都是会对tidb造成性能影响的参数。设置尽量折中。较少对性能的影响。 tidb-server节点的设置： [log] level = "warn" [prepared-plan-cache] enabled = true log-level = "warning" [raftstore] sync-log = false tikv节点的设置： log-level = "warning" [rocksdb.defaultcf] [rocksdb.writecf] block-cache

前一段时间进行jmeter压测时，一直报错，查看了下日志才发现报了一堆non http response code: org.apache.http.connectionclosedexception，直接jmeter就没发送到服务端 本想加个Constant Throughput Timer去进行控制qps从而避免错误率，可是那样qps就不是服务器的最大压力值了。 想了好几种方法，也将jmeter.properties中的httpclienc.timeout调大去尝试，还是有这个错误 最后试了一下将client implementation配置成java，结果奇迹出现了，发送不出去的错误被避免了，qps的量也上来了 总结：有加解密的情况下，默认的HTTPClinet在POST时会自动将特殊字符转义，然而Java在发送过程中却未处理； jmeter发送http请求时，implementation会有以下几种选项 JAVA：使用的是JAVA JVM提供的http方法，但有一定的限制 HttpClient4.1：使用的是Apache HttpClient4.1部件 空白：使用Http默认请求中配置或jmeter.properties中jmeter.httpsample中的配置 来源： https://www.cnblogs.com/glumer/p/11363156.html

TL;DR(too long don’t read) 限流算法：计数器、滑动窗口、漏桶、令牌桶。 限流方案：Guava的RateLimiter、Alibaba Sentinel 大家都知道，对于高并发的业务场景，我们为了保障服务的稳定，经常会祭出三大利器：缓存、熔断降级和服务限流。 服务限流作为一个核心的自保护机制，能够在非常高并发的情况下，其他机制都无法保障降级的情况下，保护系统不崩溃，以免产生雪崩效应。 我们设想这么一个场景。 名词解析，QPS(query per second 每秒查询数) 单台机器可以承受的最高QPS为 100，我们有5台机器，日常服务 QPS 为 300。 那么其实我们是毫无压力，根据前置的负载均衡服务器，每台 300/5 = 60 。可以完美提供服务。 今天，老板突然搞了一波促销，QPS 达到了 800。 好了，机器 A 的 QPS 达到了 160，已经完全扛不住了，直接宕机了。这时候集群只剩下4台机器，QPS依然是 800。平均分配到剩下的 4 台机器上，每台机器 200。就这样，机器一台一台倒下，雪崩了。 那如果我们的系统有限流，会是什么样的场景呢？ QPS 达到了800。好了，机器 A 的 QPS 达到了 160，但因为限流了100，所以机器依然正常运行，只是损失了 60 QPS 的客户，整个集群整体还是正常运行的

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