并发用户数与 TPS 之间的关系

标签: 综合新闻 | 发表时间:2014-10-14 07:29 | 作者:
出处:http://www.oschina.net/?from=rss

1. 背景

在做性能测试的时候,很多人都用并发用户数来衡量系统的性能,觉得系统能支撑的并发用户数越多,系统的性能就越好;对TPS不是非常理解,也根本不知道它们之间的关系,因此非常有必要进行解释。

2. 术语定义

Ø 并发用户数:指的是现实系统中操作业务的用户,在性能测试工具中,一般称为虚拟用户数(Virutal User),注意并发用户数跟注册用户数、在线用户数有很大差别的,并发用户数一定会对服务器产生压力的,而在线用户数只是 ”挂” 在系统上,对服务器不产生压力,注册用户数一般指的是数据库中存在的用户数。

Ø TPS Transaction Per Second, 每秒事务数, 是衡量系统性能的一个非常重要的指标,

3. Vu和TPS换算

Ø 简单例子:在术语中解释了TPS是每秒事务数,但是事务时要靠虚拟用户做出来的,假如1个虚拟用户在1秒内完成1笔事务,那么TPS明显就是1;如果某笔业务响应时间是1ms,那么1个用户在1秒内能完成1000笔事务,TPS就是1000了;如果某笔业务响应时间是1s,那么1个用户在1秒内只能完成1笔事务,要想达到1000TPS,至少需要1000个用户;因此可以说1个用户可以产生1000TPS,1000个用户也可以产生1000TPS,无非是看响应时间快慢。

Ø 复杂公式:

试想一下复杂场景,多个脚本,每个脚本里面定义了多个事务(例如一个脚本里面有100个请求,我们把这100个连续请求叫做Action,只有第10个请求,第20个请求分别定义了事务10和事务20)具体公式如下:

符号代表意义:

Vui表示的是第i个脚本使用的并发用户数

Rtj表示的是第i个脚本第j个事务花费的时间,此时间会影响整个Action时间

Rti表示的是第i个脚本一次完成所有操作的时间,即Action时间

n 表示的是第n个脚本

m 表示的是每个脚本中m个事务

那么第j个事务的TPS = Vui/Rti

总的TPS=

4. 如何获取Vu和TPS

Ø 并发用户数(Vu) 获取

新系统:没有历史数据作参考,只能通过业务部门进行评估。

旧系统:对于已经上线的系统,可以选取高峰时刻,在一定时间内使用系统的人数,这些人数认为属于在线用户数,并发用户数取10%就可以了,例如在半个小时内,使用系统的用户数为10000,那么取10%作为并发用户数基本就够了。

Ø TPS 获取

新系统:没有历史数据作参考,只能通过业务部门进行评估。

旧系统:对于已经上线的系统,可以选取高峰时刻,在5分钟或10分钟内,获取系统每笔交易的业务量和总业务量,按照单位时间内完成的笔数计算出TPS,即业务笔数/单位时间(5*60或10*60)

5. 如何评价系统的性能

针对服务器端的性能,以TPS为主来衡量系统的性能,并发用户数为辅来衡量系统的性能,如果必须要用并发用户数来衡量的话,需要一个前提,那就是交易在多长时间内完成,因为在系统负载不高的情况下,将思考时间(思考时间的值等于交易响应时间)加到脚本中,并发用户数基本可以增加一倍,因此用并发用户数来衡量系统的性能没太大的意义。

6. 相关案例

通过大量性能测试我们发现不需要用上万的用户并发去进行测试,只要系统处理业务时间足够快,几百个用户甚至几十个用户就可以达到目的。另外咨询很多专家做过的性能测试项目,基本都没有超过5000用户并发。

因此对于大型系统、业务量非常高、硬件配置足够多的情况下,5000用户并发就足够了;对于中小型系统,1000用户并发就足够了。

7. 性能测试策略

做性能测试需要一套 标准化流程及测试策略,并发用户数只是指标考虑的一个,在做负载测试的时候,一般都是按照梯度施压的方式去加用户数,而不是在没有预估的情况下,一次加几 万个用户,,交易失败率非常高,响应时间非常长,已经超过了使用者忍受范围内,这样做没有多大的意义,这就好比“有多少钱可以干多少事”一样,需要选择相 关的策略。

8. Loadrunner VS PTS

从下图对比项可以看出,PTS比Loadrunner(LR)更能让客户接受。

方向

对比项

Loadrunner

PTS

备注

基础设施

被测系统软硬件环境需要额外购买?

需要

不需要

基础设施软硬件由阿里云提供,只需要购买服务

压力机环境需要额外购买?

需要

不需要

基础设施软硬件由PTS提供,只需要购买服务

费用

费用

非常贵

便宜,按需收费

商业化工具License非常贵

功能

功能

强大

较强大

LR很多功能基本上用不到,没必要大马拉小车

易用性

操作、学习等

困难

容易

LR不易上手

稳定性

系统稳定性

较稳定

非常稳定

LR压测过程中经常出现莫名其妙错误

场景模拟

场景模拟

条件

较真实

非常真实

PTS分布在全国各地的分布式集群可以真实模拟出现实场景,而LR不太容易模拟,即使可以的话,控制机和压力机通信经常掉线


9. 总结

Ø 系统的性能由TPS决定,跟并发用户数没有多大关系。在同样的TPS下,可以由不同的用户数去压(通过加思考时间设置)。

原文出处: 《并发用户数与TPS之间的关系》

Ø 系统的最大TPS是一定的(在一个范围内),但并发用户数不一定,可以调整。

Ø 建议性能测试的时候,不要设置过长的思考时间,以最坏的情况下对服务器施压。

Ø 一般情况下,大型系统(业务量大、机器多)做压力测试,5000个用户并发就够了,中小型系统做压力测试,1000个用户并发就足够了。

相关 [并发 用户 tps] 推荐:

并发用户数与 TPS 之间的关系

- - 开源中国社区最新新闻
在做性能测试的时候,很多人都用并发用户数来衡量系统的性能,觉得系统能支撑的并发用户数越多,系统的性能就越好;对TPS不是非常理解,也根本不知道它们之间的关系,因此非常有必要进行解释. Ø 并发用户数:指的是现实系统中操作业务的用户,在性能测试工具中,一般称为虚拟用户数(Virutal User),注意并发用户数跟注册用户数、在线用户数有很大差别的,并发用户数一定会对服务器产生压力的,而在线用户数只是 ”挂” 在系统上,对服务器不产生压力,注册用户数一般指的是数据库中存在的用户数.

系统吞吐量(TPS)、用户并发量、性能测试概念和公式

- - 服务器运维与网站架构|Linux运维|X研究
PS:下面是性能测试的主要概念和计算公式,记录下:.   一个系统的吞度量(承压能力)与request对CPU的消耗、外部接口、IO等等紧密关联. 单个reqeust 对CPU消耗越高,外部系统接口、IO影响速度越慢,系统吞吐能力越低,反之越高. 系统吞吐量几个重要参数:QPS(TPS)、并发数、响应时间.

MySQL 单表插入 10w+ TPS达成

- - 淘宝网通用产品团队博客
MySQL服务端机器配置和操作系统信息,没有使用FlashCache哦:. Filesystem                        Size Used Type  Opts                                              Mountpoint. /dev/sda10                        766G  11% ext3  rw                                                /uxx.

使用 Nginx 的 keepalive patch,nginx+memcached的TPS提升7倍

- 2sin18 - Linux@SOHU
编者按:本月初 Maxim Dounin,Nginx 最活跃的开发者之一,提交了 upstream keepalive patch,支持 http/fastcgi/memcached,除了减少和 upstream 的网络开销外,也意味着能反向代理 http chunked 响应了. 搜狐技术部CMS组的同学进行了一个简单的测试:.

mysql状态查看 QPS/TPS/缓存命中率查看

- - 数据库 - ITeye博客
运行中的mysql状态查看. 对正在运行的mysql进行监控,其中一个方式就是查看mysql运行状态. (1)QPS(每秒Query量). (2)TPS(每秒事务量). (3)key Buffer 命中率. (4)InnoDB Buffer命中率. (5)Query Cache命中率. (6)Table Cache状态量.

使用tcpdump排查mysql数据库tps飙升的问题

- - OurMySQL
   上线后习惯性的观察数据库的变化. 发现数据库的tps有很大的飙升. 不过幸好在双十一的时候在数据库方面做了一些完善,虽然主库的tps有飙升,但是总体load还不是很高. 但是问题既然出现了,还是要解决的. 确定是insert update 还是 delete操作导致tps高.    既然是tps高,那就说明数据库修改的操作多了.

ES千万级TPS写入性能翻倍,400台物理机因此下线

- -
滴滴Elasticsearch引擎负责人,负责带领引擎团队深入Elasticsearch内核,解决在海量规模下Elasticsearch遇到的稳定性、性能、成本方面的问题. 曾在盛大、网易工作,有丰富的引擎建设经验. 滴滴ElasticSearch平台承接了公司内部所有使用ElasticSearch的业务,包括核心搜索、RDS从库、日志检索、安全数据分析、指标数据分析等等.

阿里如何实现秒级百万TPS?搜索离线大数据平台架构解读

- -
阿里妹导读:搜索离线数据处理是一个典型的海量数据批次/实时计算结合的场景,阿里搜索中台团队立足内部技术结合开源大数据存储和计算系统,针对自身业务和技术特点构建了搜索离线平台,提供复杂业务场景下单日批次处理千亿级数据,秒级实时百万TPS吞吐的计算能力. 一个典型的商品搜索架构如下图所示,本文将要重点介绍的就是下图中的离线数据处理系统(Offline System).

如何模拟超过 5 万用户的并发访问?

- -
来源:http://t.cn/ES7KBkW. 本文将从负载测试的角度,描述了做一次流畅的5万用户并发测试需要做的事情.. 你可以在本文的结尾部分看到讨论的记录.. 使用JMeter进行本地测试. BlazeMeter沙箱测试. 使用一个控制台和一个引擎设置Users-per-Engine的数量. 设置并测试你的集合 (1个控制台和10-14 引擎).

高并发

- - 开源软件 - ITeye博客
垂直扩展是一种用于增加单个ActiveMQ代理连接数(因而也增加了负载能力)的技术.默认情况下,. ActiveMQ的被设计成尽可高效的传输消息以确保低延迟和良好的性能. 默认情况下,ActiveMQ使用阻塞IO来处理传输连接,这种方式为每一个连接分配一个线程. 你可以为ActiveMQ代理使用非阻塞IO(同时客户端可以使用默认的传输)以减少线程的使用.