QPS，每秒查询数，常见于约束系统设计性能要求。出发点是query，适合大部分业务参考
TPS，每秒吞吐量，也用作形容数据库等业务的每秒事物数，但是实际上两个场景的T代表了不同的意思：吞吐量Throughput，事物Transaction
作为设计过GPS系统服务器集群的过来人，先笼统给出一个结论：单机性能QPS达到几千已经比较优秀了！
单数数字其实没有任何意义，我来补充下细节，业务场景式，来自车载GPS设备发起的tcp长连接，会实时的每个几秒发送一条大约100-500字节数据。服务端开发应用程序监听提前约定的端口，进行数据收发，基于IOCP(Windows)或者EPOLL(linux)等高性能应用模型，承载几万连接是没有问题的。也就是说，按照50000tcp连接来算，这个时候的qps可以推断为5000。
单个小数据包通信数据，单个查询尚且只能到5000，这还只是4层简短的tcp通信的，回到7层web应用，每个请求可轻松超过100kb，这时候继续用千为单位来形容QPS，显然已经不可能了。
有人可能想到，单机负载量，其实可以多开应用。确实，只要但应用单端口对于系统资源的占用不满载，那么完全可以通过多开方式提高负载总量。但是问题紧跟着来了，那么多的数据进来，总得占用其他资源，比如查询数据库的硬盘io，比如内网通信的网卡io，这些资源本身也是要占用资源的，因此及时努力压榨服务器性能，也终究会达到极限。几千的QPS，某些业务场景达到几万可能并不稀奇，但是现实中这样业务能有多少呢？
原文地址：
https://www.opengps.cn/Blog/View.aspx?id=842
文章的更新编辑依此链接为准。欢迎关注源站原创文章！