一般服务器的qps多大

就是说服务器在一秒的时间内处理了多少个请求 —— 我们通常是指 HTTP 请求，显然数字越大代表服务器的负荷越高、处理能力越强。

就拿我昨天刚撸的这台服务器（1核1G）来说，0QPS/S~10131QPS/S

网页链接

我用的是jmeter，写的不够专业请见谅，基本就是在一定时间内发起若干个并发连接，然后每个连接执行一次登陆操作和查询操作，对返回结果进行成功或失败判断。最终得出一个结论，比如我得到的是：

样本数量：5500；

平均连接时间：21毫秒；

95%的样本连接时间低于33毫秒；

错误率：0%；

服务器吞吐量：每秒544次；

数据流量：每秒30053KB。

当然也可以用其他软件，不过大部分都是linux下的，windows下不多，我只试用过一个pylot，需要python支持，相对jemter功能更加简单，不过设置也简单。

TPS：是Transactions Per Second的缩写，也就是事务数/秒。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。

QPS：是Queries Per Second的缩写，意思是每秒查询率，是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。

区别及理解：

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

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

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

4、QPS对应fetches/sec，即每秒的响应请求数，也即是最大吞吐能力。

参考资料

CSDN：http://blogcsdnnet/wind19/article/details/8600083

qps在2000到5000就可以算高并发了。

可能有人会觉得这个数值很小，但我要说的是单机来说已经很高了。之前在互联网大厂的api组做开发，整个api集群午高峰的峰值QPS评价在30左右，集群里的机器就有320台，平均到每台机器的qps不到1000。

每台机器的cpu使用率在50%左右，很多公司宣称自己的流量有很多，但是，最后平均到每台机器并非如此。对于直接提供api的服务单机能承受的qps峰值会相对比较低。

Load系统负载

概念：此数据指的是Linux系统的负载情况，也就是咱们平时所用Top命令时，最上面显示的数据信息（loadaverage：01，02，05。此时会显示1分钟、5分钟、15分钟的系统平均Load，很显然loadaverage的值越低，你的系统负荷越小。

简单的说下这个值应该怎么看，如果你是单核cpu，那此值为1的时候就是系统已经满负荷状态了，需要你马上去解决。但实际经验告诉我们，当系统负荷持续大于07的时候（也就是70%），就需要你马上来解决问题了，防止进一步恶化。

本质上集群部署并没有提高性能，性能看起来提高只是附加属性。

集群的主要目的有两个：

避免单点问题

扩容

单点问题

假设没有集群部署，那么就是说只有一台Server对外提供服务，如果这个Server挂掉了，那么所有的客户端就没办法访问了。

如果进行了集群部署，假设两台，通过IPhash的方式进行负载均衡，那么当其中一台Server挂掉了，那么只有大概一半的客户端受到影响（如果所有客户端都恰巧hash到了挂掉的那个Server，那就没办法了）。

如果路由有故障转移机制，那么基本可以保证一台Server挂掉了，客户端没有影响。

扩容

再说扩容，一台Server能对外提供的最大负载是一定的。当客户端数量超过了Server的最大负载时，那么就可能导致Server挂掉，或者客户端响应缓慢甚至没有响应的问题。

通过集群部署，可以增加最大客户端数量。假设一台Server能同时支持1000个客户端访问，那两台Server理论就能支持2000个客户端同时访问。

性能

上面说了，集群部署并没有提高性能。集群只是多开通了通道。

举个例子，假如有个水池，原来一个水管向水池里注水，集群部署后就是多个水管向水池里注水。单个水管的速度并没有变化，但是流量变大了。

看起来性能提高的原因是，性能一般是通过TPS/QPS来定义的，也就是一秒内完成的请求数量。

集群后，因为流量大了，那么TPS肯定就高了。

但是，TPS/QPS计算的是系统的最大可运行负载。就是一个系统在这个负载下可以正常的长时间对外服务，超过了这个负载就可能导致响应变慢或没有响应、甚至导致服务器直接挂掉。而一般情况下都会做冗余，所以系统基本不会长时间运行在最大可运行负载下。

所以一般情况下集群对性能的影响有限，极端情况还可能降低性能。假设一台Server能支持1000个客户端，你部署了两台Server，而实际只有10个客户端进行访问，远达不到单台Server的负载，加上集群需要路由算法，可能性能上就比单台Server稍微慢了一点点。

背景：昨天一QQ群里的兄弟问了个问题：并发数 和 TPS 有什么联系吗？我在微信里作了下简单回答如下，顺带今天了解下其它参数。

Q：

并发数 和 TPS 有什么联系吗？

A:

对长连接无联系，tps是响应时间，并发是一次能接受多少个连接（长时间连接上的不一定要立即响应，TPS不是考量的重点）。而像http这样的并发数大了响应时间可能较长（处理不过来），它们是恒量一个系统是否健壮的不可缺少的互补参数。

Q：

我总觉得 并发量大了 会导致响应时间变长 还有这些对软件的压力测试 和 具体的硬件有联系吗？ 还有 比如nginx qps 可以再2k以上 这个数值在不同的机器上都是差不多稳定的吗？ PS： 你还在公司加班？

A：软件必须要和硬件互补才行，对于nginx这样的已经到很高水平了，并法高出现tps急剧降低可能是业务太重，更多是直连db等拖累，这要从架构高耦合低内聚上作切割，横向纵向分拆等扩展模式，想榨干硬件的想法对小公司不切实际，大公司会根据自身业务而不是选nginx这样的通用服务器软件，都会定做，以节省机器省成本。我下班了，在家了呵呵。

摘录：

QPS（TPS）：每秒钟request/事务 数量

并发数： 系统同时处理的request/事务数

响应时间： 一般取平均响应时间

（很多人经常会把并发数和TPS理解混淆）

理解了上面三个要素的意义之后，就能推算出它们之间的关系：

QPS（TPS）= 并发数/平均响应时间

一个系统吞吐量通常由QPS（TPS）、并发数两个因素决定，每套系统这两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统的吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换、内存等等其它消耗导致系统性能下降。

域名解析防护QPS指DNSQuery查询攻击攻击的阀值量，其工作原理是向被攻击的服务器发送大量的域名解析请求，一般这些请求解析的域名是是网

络上不存在的域名，或者是随机生成的。当被攻击的DNS

服务器在接收到域名解析请求的时，首先在服务器上查找是否有对应的缓存，如果查找不到并且该域名无法直接由服务器解析，那么DNS

服务器会向其上层DNS服务器递归查询域名信息。当然，域名解析的过程给服务器带来了很大的负载，所以当每秒钟域名解析请求超过一定的数量时，就会造成

DNS服务器解析域名超时这种情况的出现。

QPS(Query Per Second)，即域名查询攻击防护级别，例如 < 500,000 QPS，表示系统可为客户抵御不高于50万次防护请求，当超过此频度的攻击请求时，客户可以选择更高级别的套餐来抵御攻击，提供防护能力。