TPS QPS

TPS： Transactions Per Second

QPS： queries per second

1、TPS即每秒处理事务数，包括：”用户请求服务器”、”服务器自己的内部处理”、”服务器返回给用户”，这三个过程，每秒能够完成N个这三个过程，TPS也就是3；

2、QPS基本类似于TPS，但是不同的是，对于一个页面的一次访问，形成一个TPS；但一次页面请求，可能产生多次对服务器的请求，服务器对这些请求，就可计入QPS之中

原文地址：https://www.cnblogs.com/newworldnewstart/p/8450430.html

时间： 2024-08-03 22:38:19

TPS QPS的相关文章

【MySQL】计算 TPS,QPS 的方式

在做db基准测试的时候,qps,tps 是衡量数据库性能的关键指标.本文比较了网上的两种计算方式.先来了解一下相关概念. 概念介绍: QPS:Queries Per Second 查询量/秒,是一台服务器每秒能够相应的查询次数,是对一个特定的查询服务器在规定时间内所处理查询量多少的衡量标准. TPS : Transactions Per Second 是事务数/秒,是一台数据库服务器在单位时间内处理的事务的个数. 如何计算: 从网上查看如果获取mysql 的qps,tps

利用脚本获取mysql的tps,qps等状态信息

#!/bin/bash mysqladmin -uroot -p'123456' extended-status -i1|awk 'BEGIN{local_switch=0;print "QPS Commit Rollback TPS Threads_con Threads_run \n------------------------------------------------------- "} $2 ~ /Queries$/ {q=$4-lq;lq=$4;} $2 ~ /Com

性能测试TPS目标值确定-二八原则

在性能测试中通常使用二八原则来量化业务需求. 二八原则:指80%的业务量在20%的时间里完成. TPS(QPS)=并发数/响应时间例:如某个公司1000个员工,在周五下午3点-5点有90%的员工登陆公司周报系统则:业务量=1000个,时间=2x60x60=7200秒根据二八原则来计算3点到5点的TPS=(90%*业务量*80%)/(20%*时间)=0.9*1000*0.8/(0.2*7200)=0.5 注:二八原则计算的结果并非在线并发用户数,是系统要达到的处理能力(吞吐量)

MyCat - 使用篇（3）

数据库路由中间件MyCat - 使用篇(3) 全局序列号数据切分后,原有的关系数据库中的主键约束在分布式条件下将无法使用,因此需要引入外部机制保证数据唯一性标识,这种保证全局性的数据唯一标识的机制就是全局序列号(sequence). 全局序列号有很多实现的方式,比如本地配置文件,或者拿一个分片节点保存全局序列号,但是这么做都有单点故障的问题,从架构上看不推荐这么做. 全局序列号还是推荐用独立的id生成器服务去实现最佳! 安装准备环境 Red Hat Enterprise Linux Serv

A little problem for pt-pmp

We use the pt-pmp (a variety for pmp !http://poormansprofiler.org/! by Percona ) tool a lot to analyze our online MySQL problem. But when we execute the pmp, we have found tps/qps of mysqld drop a lot, such as: [10225s] threads: 256, tps: 8738.19, r

如何做性能测试

偶然间看到了阿里中间件Dubbo的性能测试报告,我觉得这份性能测试报告让人觉得做这性能测试的人根本不懂性能测试,我觉得这份报告会把大众带沟里去,所以,想写这篇文章,做一点科普. 首先,这份测试报告里的主要问题如下: 1)用的全是平均值.老实说,平均值是非常不靠谱的. 2)响应时间没有和吞吐量TPS/QPS挂钩.而只是测试了低速率的情况,这是完全错误的. 3)响应时间和吞吐量没有和成功率挂钩. 为什么平均值不靠谱关于平均值为什么不靠谱,我相信大家读新闻的时候经常可以看到,平均工资,平均房价,平均

数据库相关中间件介绍

数据库相关中间件介绍详见:http://blog.yemou.net/article/query/info/tytfjhfascvhzxcyt412 这里主要介绍互联网行业内有关数据库的相关中间件.数据库相关平台主要解决以下三个方面的问题: 为海量前台数据提供高性能.大容量.高可用性的访问为数据变更的消费提供准实时的保障高效的异地数据同步应用层通过分表分库中间件访问数据库,包括读操作(Select)和写操作(update, insert和delete等,DDL, DCL).写操作会在数据

高并发限流策略

在开发高并发系统时有三把利器用来保护系统:缓存.降级和限流.缓存的目的是提升系统访问速度和增大系统能处理的容量,可谓是抗高并发流量的银弹:而降级是当服务出问题或者影响到核心流程的性能则需要暂时屏蔽掉,待高峰或者问题解决后再打开:而有些场景并不能用缓存和降级来解决,比如稀缺资源(秒杀.抢购).写服务(如评论.下单).频繁的复杂查询(评论的最后几页),因此需有一种手段来限制这些场景的并发/请求量,即限流. 限流的目的是通过对并发访问/请求进行限速或者一个时间窗口内的的请求进行限速来保护系统,一旦达到

走过第一个双十一的收获----性能监控篇

一.网卡流量监控 1.网卡流量监控的意义是: 如果网卡流量上限设置过小,就会成为一个web系统的性能瓶颈.记得勤泽说过的,曾经一个系统设置网卡流量上限为15M,出现了大流量的时候系统雪崩的情况.但是这个只是特例情况,正常情况下,这个指标是不会成为.也不应该成为一个系统的性能瓶颈的. 2.我们系统中目前的ifout出流量平均值为26319.93KByte/s,ifin进流量的平均值为50760.54KBytes/s..都是在可接受的范围内 3.如果当天的aliMonitor出现问题,在linux下