qps

我们在日常工作中经常会听到QPS/TPS这些名词，也会经常被别人问起说你的系统吞吐量有多大。这个问题从业务上来讲，可以理解为应用系统每秒钟最大能接受的用户访问量。或者每秒钟最大能处理的请求数； QPS: 每秒钟处理完请求的次数；注意这里是处理完。具体是指发出请求到服务器处理完成功返回结果。可以理解在server中有个counter，每处理一个请求加1，1秒后counter=QPS。 TPS：每秒钟处理完的事务次数，一般TPS是对整个系统来讲的。一个应用系统1s能完成多少事务处理，一个事务在分布式处理中，可能会对应多个请求，对于衡量单个接口服务的处理能力，用QPS比较多。 并发量：系统能同时处理的请求数 RT：响应时间，处理一次请求所需要的平均处理时间 计算关系： QPS = 并发量 / 平均响应时间 并发量 = QPS * 平均响应时间 来源： oschina 链接： https://my.oschina.net/u/3101476/blog/1625454

一、PV/UV/IP 1.1 名词解释 PV (Page View) 页面浏览量 用户每一次对网站中的每个页面访问均被记录1次。 用户对同一页面的多次刷新，访问量累计。 UV (Unique Visitor) 独立访客 通过访问电脑的cookies实现。 IP 通过访问电脑的ip实现。 1.2 UV、IP的区别 1. 比如你是ADSL拨号上网，拨一次号自动分配一个IP，进入了网站，就算一个IP；断线了而没清理Cookies，又拨号一次自动分配一个IP，又进入了同一个网站，又统计到一个IP，这时统计数据里IP就显示统计了2次。UV没有变，是1次。 2. 同一个局域网内2个人，在2台电脑上访问同一个网站，他们的公网IP是相同的。IP就是1，但UV是2。 二、QPS/TPS QPS：Queries Per Second意思是“每秒查询率”，是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。 TPS：TransactionsPerSecond的缩写，也就是事务数/秒。它是软件测试结果的测量单位。 一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数，最终利用这些信息来估计得分。客户机使用加权协函数平均方法来计算客户机的得分

整合Sentinel 应用整合Sentinel 在dependencies中添加依赖，即可整合Sentinel <dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId> </dependency> 搭建Sentinel控制台 可以从这个地址：https://github.com/alibaba/Sentinel/releases 下载控制台应用。因为下载速度较慢，给出一个我下载的版本（1.6.3） 百度云地址：链接: https://pan.baidu.com/s/1UV4OzfjfuBZQfpPb28z0sw&shfl=sharepset 密码: i68g 运行命令启动控制台： java -jar sentinel-dashboard-1.6.3.jar 打开浏览器，输入http://localhost:8080进入控制台页面（账号密码默认sentinel） 应用整合Sentinel控制台 添加配置文件： spring: cloud: sentinel: transport: # 指定sentinel控制台地址 dashboard: localhost:8080 PS： 其他的配置项 spring: cloud:

kubelet 参数详解 基本参数 --allow-privileged=true #允许容器请求特权模式 --anonymous-auth=false #不允许匿名请求到 kubelet 服务（默认 true ） --authentication-token-webhook=true #使用 TokenReview API 来确定不记名令牌的身份验证 --authorization-mode=Webhook #kubelet 服务的授权模式，Webhook 模式使用 SubjectAccessReview API 来确定授权。(默认“AlwaysAllow”) --cadvisor-port=0 #本地 cAdvisor 端口（默认 4194） --cgroup-driver=cgroupfs #kubelet 用来操作主机上的 cgroups 驱动，可选值有：“cgroupfs”和“systemd”（默认“cgroupfs”） --client-ca-file=/etc/kubernetes/pki/ca.crt #集群ca证书 --cluster-dns=10.96.0.10 #DNS 服务器的IP地址列表，逗号分隔。 --cluster-domain=xxx.xxx.xxx #集群域名, kubelet 将配置所有容器除了主机搜索域还将搜索当前域。 --cni-bin

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

Memcached可以利用多核优势，单实例吞吐量极高，可以达到几十万QPS（取决于key、value的字节大小以及服务器硬件性能，日常环境中QPS高峰大约在4-6w左右）。适用于最大程度扛量。 支持直接配置为session handle。Memcached可以利用多核优势，单实例吞吐量极高，可以达到几十万QPS（取决于key、value的字节大小以及服务器硬件性能，日常环境中QPS高峰大约在4-6w左右）。适用于最大程度扛量。 支持直接配置为session handle。Memcached可以利用多核优势，单实例吞吐量极高，可以达到几十万QPS（取决于key、value的字节大小以及服务器硬件性能，日常环境中QPS高峰大约在4-6w左右）。适用于最大程度扛量。 支持直接配置为session handle。Memcached可以利用多核优势，单实例吞吐量极高，可以达到几十万QPS（取决于key、value的字节大小以及服务器硬件性能，日常环境中QPS高峰大约在4-6w左右）。适用于最大程度扛量。 支持直接配置为session handle。Memcached可以利用多核优势，单实例吞吐量极高，可以达到几十万QPS（取决于key、value的字节大小以及服务器硬件性能，日常环境中QPS高峰大约在4-6w左右）。适用于最大程度扛量。 支持直接配置为session handle

前言： 原作：孤独烟。因修改不当之处欢迎指出！ 大家好，我是小架架。 今天一大早就起来水文章了。这篇文章我个人感觉虽然含金量不是特别大，估计大家大概5分钟左右就能看完！到底是因为什么呢，因为平时干货文章分享得有点多，今天的话就一顿截图写几个命令就搞定了，所以含金量不高。 然后，我们来看一下近期有一段聊天记录 如下 看到这里，不要吃惊，不要惊讶！看下文哦！ 所以，该吹的牛皮都吹出去了。所以写个文章，自己给自己圆上！ 正文 QPS是什么 我们先回忆一下，QPS的概念如下所示: QPS（Query Per Second）：每秒请求数，就是说服务器在一秒的时间内处理了多少个请求。 那我们怎么估出每秒钟能处理多少请求呢？ OK，用日志来估计！那日志怎么记录呢，细分下来，有两种方式。 方式一:自己在接口里记录 这种方式指的是在你的接口里，日志记录了能体现该接口特性的，并具有唯一性的字符串！ 例如，下面这一段代码 @RestController @RequestMapping("/home") public class IndexController { //省略 @RequestMapping("/index") String index() { logger.info("渣渣烟"); return "index"; } } 假设现在我要统计index这个接口的QPS！ OK

一个成熟的数据库架构并不是一开始设计就具备高可用、高伸缩等特性的，它是随着用户量的增加，基础架构才逐渐完善。这篇文章主要谈谈MySQL数据库在发展周期中所面临的问题及优化方案，暂且抛开前端应用不说，大致分为以下五个阶段： 阶段一：数据库表设计 项目立项后，开发部门根据产品部门需求开发项目。 开发工程师在开发项目初期会对表结构设计。对于数据库来说，表结构设计很重要，如果设计不当，会直接影响到用户访问网站速度，用户体验不好！这种情况具体影响因素有很多，例如慢查询（低效的查询语句）、没有适当建立索引、数据库堵塞（锁）等。当然，有测试部门的团队，会做产品测试，找Bug。 由于开发工程师重视点不同，初期不会考虑太多数据库设计是否合理，而是尽快完成功能实现和交付。等项目上线有一定访问量后，隐藏的问题就会暴露，这时再去修改就不是这么容易的事了！ 阶段二：数据库部署 是时候运维工程师出场了，项目上线。 项目初期访问量一般是寥寥无几，此阶段Web+数据库单台部署足以应对在1000左右的QPS（每秒查询率）。考虑到单点故障，应做到高可用性，可采用MySQL主从复制+Keepalived实现双机热备。主流HA软件有：Keepalived（推荐）、Heartbeat。 阶段三：数据库性能优化 如果将MySQL部署到普通的X86服务器上，在不经过任何优化情况下，MySQL理论值正常可以处理1500左右QPS

1.网络请求时间 2.数据库查询的时间 数据库性能指标 TPS:每秒事务数（一秒钟服务器处理的事务数，事务指，请求出去到响应回来的整个过程的时间） QPS:每秒查询量（就是数据库每秒执行的SQL数量，包含insert/select/update/delete） 连接数（连接数是否释放） 查询缓存（不进行select，直接从缓存拿数据，缓存机制可以设置） 事务数的计算：Com_commit 提交次数（成功的事务） Com_rollback回滚次数（失败的事务）相加 QPS的计算 Questions / Uptime 即可得到的该指标的值 QPS查询：mysql>show global status like 'Questions'; mysql>show global status like 'Uptime' 数据库容易出现的问题： 1.连接池容易爆掉 2.慢查询 Jmeter需要一个插件才能连接数据库，一个mysql-connector-java-5.1.7-bin.jar包,放在apache-jmeter-4.0>lib>ext下即可 连接数据库第一步： 1.“添加”-》“配置元件”-》“JDBC Connection Configuration” QPS （ Queries Per Second ，每秒查询数） TPS （ Transactions Per Second

在日常的工作中经常会讲到吞吐量、并发量等概念，查询了下相关资料，在这里记录下对吞吐量（TPS）、QPS、并发数、响应时间（RT）几个概念做下了解，查自百度百科。 响应时间(RT) 　　响应时间是指系统对请求作出响应的时间。直观上看，这个指标与人对软件性能的主观感受是非常一致的，因为它完整地记录了整个计算机系统处理请求的时间。由于一个系统通常会提供许多功能，而不同功能的处理逻辑也千差万别，因而不同功能的响应时间也不尽相同，甚至同一功能在不同输入数据的情况下响应时间也不相同。所以，在讨论一个系统的响应时间时，人们通常是指该系统所有功能的平均时间或者所有功能的最大响应时间。当然，往往也需要对每个或每组功能讨论其平均响应时间和最大响应时间。 吞吐量(Throughput) 吞吐量是指系统在单位时间内处理请求的数量。对于无并发的应用系统而言，吞吐量与响应时间成严格的反比关系，实际上此时吞吐量就是响应时间的倒数。前面已经说过，对于单用户的系统，响应时间（或者系统响应时间和应用延迟时间）可以很好地度量系统的性能，但对于并发系统，通常需要用吞吐量作为性能指标。 　　对于一个多用户的系统，如果只有一个用户使用时系统的平均响应时间是t，当有你n个用户使用时，每个用户看到的响应时间通常并不是n×t，而往往比n×t小很多（当然，在某些特殊情况下也可能比n×t大，甚至大很多）