连 QPS,TPS,RT,PV,UV 这些指标都不知道是什么意思,还敢说自己懂高并发?

简介: 连 QPS,TPS,RT,PV,UV 这些指标都不知道是什么意思,还敢说自己懂高并发?

废话不多说,直接开始。


QPS


原理:每天 80% 的访问集中在 20% 的时间里,这 20% 时间叫做峰值时间。


公式:( 总 PV 数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS)。


PV(page view)即页面浏览量,通常是衡量一个网络新闻频道或网站甚至一条网络新闻的主要指标。网页浏览数是评价网站流量最常用的指标之一,简称为 PV。


再来看一个计算机器数量的公式:


需要的机器数量:峰值时间每秒 QPS / 单台机器的 QPS。


举个例子,每天 300w PV 打在单台机器上,这台机器需要多少 QPS?


( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)。


一般需要达到 139 QPS,因为是峰值。(200 万 PV 才有 100 峰值 QPS)


TPS


TPS:Transactions Per Second(每秒传输的事物处理个数),即服务器每秒处理的事务数。


TPS 包括一条消息入和一条消息出,加上一次用户数据库访问。


一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时,收到服务器响应后结束计时,以此来计算使用的时间和完成的事务个数。

一般的,评价系统性能均以每秒钟完成的技术交易的数量来衡量,系统整体处理能力取决于处理能力最低模块的 TPS 值。


RT(响应时长)


响应时间是指:系统对请求作出响应的时间(一次请求耗时)。


直观上看,这个指标与人对软件性能的主观感受是非常一致的,因为它完整地记录了整个计算机系统处理请求的时间。由于一个系统通常会提供许多功能,而不同功能的处理逻辑也千差万别,因而不同功能的响应时间也不尽相同,甚至同一功能在不同输入数据的情况下响应时间也不相同。所以,在讨论一个系统的响应时间时,人们通常是指该系统所有功能的平均时间或者所有功能的最大响应时间。当然,往往也需要对每个或每组功能讨论其平均响应时间和最大响应时间。


对于单机的没有并发操作的应用系统而言,人们普遍认为响应时间是一个合理且准确的性能指标。需要指出的是,响应时间的绝对值并不能直接反映软件的性能的高低,软件性能的高低实际上取决于用户对该响应时间的接受程度。


对于一个游戏软件来说,响应时间小于 100 毫秒应该是不错的,响应时间在 1 秒左右可能属于勉强可以接受,如果响应时间达到 3 秒就完全难以接受了。而对于编译系统来说,完整编译一个较大规模软件的源代码可能需要几十分钟甚至更长时间,但这些响应时间对于用户来说都是可以接受的。


Load(系统负载)


Linux 的 Load 是一个让新手不太容易了解的概念。Load 就是一定时间内计算机有多少个 active_tasks,也就是说是计算机任务执行队列的长度,CPU 计算的队列。


top/uptime 等工具默认会显示 1 分钟、5 分钟、15 分钟的平均 Load。


具体来说,平均 Load 是指,在特定的一段时间内统计的正在 CPU 中运行的(R 状态)、正在等待 CPU 运行的和处于不可中断睡眠的(D 状态)任务数量的平均值。

       

最后,说一下 CPU 使用率和 Load 的关系吧。如果主要是 CPU 密集型的程序在运行,那么 CPU 利用率高,Load 一般也会比较高。


If CPU utilization is near 100 percent (user + nice  +  system), the workload sampled is CPU-bound


而 I/O 密集型的程序在运行,可能看到 CPU 的 %user, %system 都不高,%iowait 可能会有点高,这时的 Load 通常也比较高。


同理,程序读写慢速 I/O 设备(如磁盘、NFS)比较多时,Load 可能会比较高,而 CPU 利用率不一定高。这种情况,还经常发生在系统内存不足并开始使用 swap 的时候,Load 一般会比较高,而 CPU 使用率并不高。


PV


页面访问次数:Page View。


UV


访客数(去重复):Unique Visitor。

以上。



目录
相关文章
|
消息中间件 JavaScript 小程序
面试官:你了解 QPS、TPS、RT、吞吐量 这些高并发性能指标吗?
面试官:你了解 QPS、TPS、RT、吞吐量 这些高并发性能指标吗?
|
监控 前端开发 JavaScript
不了解 QPS、TPS、RT、并发数、吞吐量,劝你简历别写熟悉高并发
分布式、微服务、Service Mesh目前都是大家耳熟能详的词语了,现在随便一个互联网公司说出来大家都是在搞微服务。 但我们搞来搞去,怎么样来衡量一个应用当前的状态到底是怎么样的?到底需不需要扩容?是需要横向扩容还是进行项目重构?
|
缓存 负载均衡 NoSQL
一例千万级pv高性能高并发网站架构
一例千万级pv高性能高并发网站架构  http://blog.liuts.com/post/234/ 受CU管理员的邀请参考“千万级pv高性能高并发网站架构与设计交流探讨帖”主题的交流,发表了一案例与大家分享。
1206 0
|
6月前
|
消息中间件 Java Linux
2024年最全BATJ真题突击:Java基础+JVM+分布式高并发+网络编程+Linux(1),2024年最新意外的惊喜
2024年最全BATJ真题突击:Java基础+JVM+分布式高并发+网络编程+Linux(1),2024年最新意外的惊喜
|
5月前
|
缓存 NoSQL Java
Java高并发实战:利用线程池和Redis实现高效数据入库
Java高并发实战:利用线程池和Redis实现高效数据入库
483 0
|
3月前
|
监控 算法 Java
企业应用面临高并发等挑战,优化Java后台系统性能至关重要
随着互联网技术的发展,企业应用面临高并发等挑战,优化Java后台系统性能至关重要。本文提供三大技巧:1)优化JVM,如选用合适版本(如OpenJDK 11)、调整参数(如使用G1垃圾收集器)及监控性能;2)优化代码与算法,减少对象创建、合理使用集合及采用高效算法(如快速排序);3)数据库优化,包括索引、查询及分页策略改进,全面提升系统效能。
48 0
|
5月前
|
存储 NoSQL Java
探索Java分布式锁:在高并发环境下的同步访问实现与优化
【6月更文挑战第30天】Java分布式锁在高并发下确保数据一致性,通过Redis的SETNX、ZooKeeper的临时节点、数据库操作等方式实现。优化策略包括锁超时重试、续期、公平性及性能提升,关键在于平衡同步与效率,适应大规模分布式系统的需求。
168 1
|
4月前
|
算法 Java 调度
高并发架构设计三大利器:缓存、限流和降级问题之使用Java代码实现令牌桶算法问题如何解决
高并发架构设计三大利器:缓存、限流和降级问题之使用Java代码实现令牌桶算法问题如何解决
|
4月前
|
监控 网络协议 Java
Java面试题:解释Java NIO与BIO的区别,以及NIO的优势和应用场景。如何在高并发应用中实现NIO?
Java面试题:解释Java NIO与BIO的区别,以及NIO的优势和应用场景。如何在高并发应用中实现NIO?
74 0