最近公司要做服务端压力测试，我来负责；
产品：我要求系统必须满足 300 并发的要求，系统用起来要流畅；
产品给出的指标就是上面两个：1.300 并发；2. 流畅；OK，那就开始做吧；如果放在以前刚刚开始接触压测的时候，我肯定是写好脚本，直接上 300 个并发，在一些节点加思考时间，模拟用户行为来压测就行；但是这样是没法准确来模拟 300 个真正用户的操作场景的，可以说在脚本方面下功夫，无论如何也没法准确的模拟一定数量的用户对系统的操作的；
这个时候我们能不能通过抓取后台的服务日志，看一下每个服务在一段时间内，真正承受的压力是多少呢？我们可以看 QPS，比如一天内最大的值是 100QPS，这个时候我们就知道服务最大接到 的请求压力是 100QPS，这个时候，我们就可以通过加大并发量，让服务承受的压力一直阶梯增加到 50QPS 80QPS 100QPS 120QPS， 不用管 jmeter 加的并发量是多大，只调整 jmeter 的并发量，看服务端承受的 QPS 能否达到最大值就可以了！也不用再想法模拟飘忽不定的用户真实操作了；当 jmeter 设置到一定并发量，后台服务承受的压力是 100qps 了，这个时候系统还没有问题的话就满足产品的要求了；我们还可以接着加大并发量，直到压出系统的瓶颈；
这个过程的一切，我们只看后台服务的 qps，并发量只是我们达到服务承受压力的一个手段而已；
这是个人的一些思考，欢迎性能大咖能提出质疑或者性能测试的方法，真诚跟大家交流请教，谢谢！
最后 @ 一下大神@ZeeBJ，还请指正，感谢！
每个服务端承受了多少,不是根据你们的业务模型去确定的吗?
吉吉里
回复
赞同，某些系统没用并发数的概念，或者说并发数并不指代实际存在的用户，这种时候只看 TPS 是可以的，此时并发数只是增大压力的作用，但是针对某些业务系统而言，并发数是有实际意义的，指代的就是实际存在的用户，这种时候并发数就是有意义的，此时并发数是需要作为一个测试点的。比如某业务系统处理能力要求 300TPS，300TPS 假如可以用 50 并发测到，那么用 100 并发也绝对可测到 (加间隔时间就可以)，那么只考虑 TPS，测试并发数为 50，满足 300TPS 指标，测试通过，但是未验证并发数这个测试点，那么有可能你的系统在 100 并发出现问题，比如无法登陆，或者登陆时间过长等。
前排坐好学习
每个服务端承受了多少,不是根据你们的业务模型去确定的吗?
卡丁车卡丁丁
回复
我说的这个是在系统已经在是使用的情况下，有历史数据可以参考；即我们知道这个服务历史最高 qps 是多大，然后参考这个 qps 为基准来压测看是否满足这个最大的 qps; 如果说是一个新系统上线的话，qps 这块还没有一个历史最高参考值；你说的服务端承受了多少是指 qps 吗？还是用户在线数呢？
卡丁车卡丁丁
回复
但是你的并发量怎么确定呢？其实多少用户在线上使用和设置同样数量的并发量，对系统产生的压力是完全不同的；及时加上思考时间，集合点等尽量模拟用户行为，但是还是是不一样的
流畅？这个定义的太飘忽不定了。
当然还是看你们的产品吧，压测压了就压了，顺便也压下极限，卡不卡无所谓了，别完全压死无法自动恢复了那问题就大了。
我不明白你们为什么做业务系统的性能测试总提 qps 呀、rps 呀之类的
一个用户操作，对应后端很可能就是一个 API，一个 API 九成九的概率就是用一个事务来管理，一个事务里面包含多次依赖（其他服务）调用或者数据库读写，用户所关注的不就是这个完整的事务的响应吗，transaction per second 这个指标到底哪里不好以致于大家都喜欢拿 qps 来衡量性能呢，你们是在做数据库中间件或者消息中间件的性能基准测试吗？
抛砖引玉：
1、大部分情况，服务端容量就是看 QPS，或则说（QPS，Latency，Error_Rate,CPU,Memory) 这几个组合。单纯谈一个或几个指标是没有意义的，比如 QPS 很高，latency 很大，或者错误率很高，这都是无效的
2、大部分情况下，服务端容量就是看 QPS，并发数只是我们达到这个 QPS 的手段 --- 这个是 OK 的
3、为什么说大部分情况下呢，因为对于某些场景下，并发数有特殊的含义。比如说 websocket 协议，比如游戏基于 socket 长链接这种情况下，系统看的是新建连接数，和连接保持数，这个是 QPS 解决不了的。
4、就楼主这个情况，300 并发 != 300QPS。 产品告诉你 300 并发，我理解是最大同时支持 300 个用户并发操作，需要根据用户行为模型来预估最高 QPS。这种情况下，可以看看线上高峰期时并发数是多少，然后对应的各个接口的 QPS 是多少，然后计算出 300 并发下，各个接口的 QPS 是多少，然后需要按照这个数据来进行压测。
三百人并发是什么意思呢？ 三百人同时在线但是在做不同的事情，还是有一千人在线但是其中三百人同时在做同一件事情？
吉吉里
回复
赞同，某些系统没用并发数的概念，或者说并发数并不指代实际存在的用户，这种时候只看 TPS 是可以的，此时并发数只是增大压力的作用，但是针对某些业务系统而言，并发数是有实际意义的，指代的就是实际存在的用户，这种时候并发数就是有意义的，此时并发数是需要作为一个测试点的。比如某业务系统处理能力要求 300TPS，300TPS 假如可以用 50 并发测到，那么用 100 并发也绝对可测到 (加间隔时间就可以)，那么只考虑 TPS，测试并发数为 50，满足 300TPS 指标，测试通过，但是未验证并发数这个测试点，那么有可能你的系统在 100 并发出现问题，比如无法登陆，或者登陆时间过长等。
从产品模型和用户模型评估很难，需要很多维度，反而直接看线上历史峰值 QPS 是最准确的，然后通过接口或事务比例来构成业务场景即可。性能测试做到线上峰值的 3 倍，上线之后理论上是绰绰有余的。但是要考虑稳定性，因为很多问题是长时间压力才能暴漏的。
吉吉里
回复
这种情况下，可以看看线上高峰期时并发数是多少，然后对应的各个接口的 QPS 是多少—— 请教一下，这里所说的各个接口的 QPS，是指接口每秒接收到的请求，还是每秒接到并处理完成的请求呢？
在路上
回复
历史峰值 QPS——您好，请问一下线上看历史峰值的 QPS，一般我们在后台能看到的应该是每个接口每秒中接收到的请求吧，即 QPS, 但是看好多文章说 QPS 又是指每秒中处理的请求数？所以是指哪个呢
弱弱的问一下，这个性能指标是怎么得到啊，比如这个要求的并发数
朱zhu
回复
要找哪些接口：定位到最前面的接口就行，即用户可以直接访问到的接口。
需要找什么数据：QPS（ quests per second），后台统计的是，每个接口每秒接受的请求 (这就是该接口的 QPS)，就是性能测试需要的数据。
怎么模拟场景：按照线上统计的接口比例，进行模式
在路上
回复
谢谢指教啊，这样的话 QPS 其实要分为两个概念了吗？后端接口讲 QPS，就是指每秒接收到的请求数；如果看接口每秒钟能处理多少个请求，可以跟据 Jmeter 工具，比如 300 并发/平均响应时间= QPS(接口处理能力)？ QPS 可以有不同的理解
性能测试分两种，容量测试和压力测试。（当然高楼是说性能测试其实就一种，不用分那么多，我这么说是便于理解）
你的问题，看起来你是把这两者混在一起了。细看你的要求更接近压力测试。
我遇到的 90% 吧，Jmeter 的的范畴，剩下的，最应该用流量回放的方式搞，但是还是使用了 Jmeter 搞定。
楼上的各位都好厉害呀～ 能在 testhome 多发写这方面的帖子吗？
在 testhome 上其他热帖，很少讨论测试技能这块的，，，，， 看到标题都不想点进去。。。。。