飞机号：@hpx639
tps和并发数的区别-tps和并发数的关系
wasd8456时间2024-08-22 14:26:05分类SIP Trunk浏览112
tps太低是意思？
TPS通俗的定义是系统吞吐量，也就是每秒系统处理业务的数量。***如TPS每秒并发太低，很容易造成网络严重拥堵；提升TPS处理速度，又会牺牲部分区块链的安全性或稳定性。
从现实应用来看，百万TPS的处理速度在现有环境中的应用价值并不是那么必须，并且区块链技术不能仅仅依赖提升TPS去解决所有的问题。
TPS太低的原因是：
1、网络带宽
在压力测试中，有时候要模拟大量的用户请求，如果单位时间内传递的数据包过大，超过了带宽的传输能力，那么就会造成网络***竞争，间接导致服务端接收到的请求数达不到服务端的处理能力上限。
2、连接池
可用的连接数太少，造成请求等待。连接池一般分为服务器连接池（比如Tomcat）和数据库连接池（或者理解为最大允许连接数也行）。
3、垃圾回收机制
从常见的应用服务器来说，比如Tomcat，因为j***a的的堆栈内存是动态分配，具体的回收机制是基于算法，如果新生代的Eden和Survivor区频繁的进行Minor GC，老年代的full GC也回收较频繁，那么对TPS也是有一定影响的，因为垃圾回收其本身就会占用一定的***。
4、数据库配置
高并***况下，如果请求数据需要写入数据库，且需要写入多个表的时候，如果数据库的最大连接数不够，或者写入数据的SQL没有索引没有绑定变量，抑或没有主从分离、读写分离等，就会导致数据库事务处理过慢，影响到TPS。
5、通信连接机制
串行、并行、长连接、管道连接等，不同的连接情况，也间接的会对TPS造成影响。
6、硬件***
包括CPU（配置、使用率等）、内存（占用率等）、磁盘（I/O、页交换等）。
7、压力机
比如jmeter，单机负载能力有限，如果需要模拟的用户请求数超过其负载极限，也会间接影响TPS（这个时候就需要进行分布式压测来解决其单机负载的问题）。
8、压测脚本
还是以jemter举个例子，之前工作中同事遇到的，进行阶梯式加压测试，最大的模拟请求数超过了设置的线程数，导致线程不足。提到这个原因，想表达意思是：有时候测试脚本参数配置等原因，也会影响测试结果。
9、业务逻辑
业务解耦度较低，较为复杂，整个事务处理线被拉长导致的问题。
10、系统架构
比如是否有缓存服务，缓存服务器配置，缓存命中率、缓存穿透以及缓存过期等，都会影响到测试结果。
阿里云的服务器4核8g，10M带宽并发访问，能支持多少用户？
支持多少用户和并发性能是不同的，一亿用户，但活跃量不到一万，那对一般的业务完全没有压力，所以论支持多少用户没有意义的。4核8g的服务一般的业务qps在5000左右，相当50000活跃用户，这和业务复杂度有关。
蟹妖~~关注极迭代，和小伙伴一起看↗↗↗4核8G+10M带宽属于比较好的机器了，能够满足大部分场景的需要。但要说能支持多少用户，就不能这样拍脑袋得到答案。用户支撑数量是由很多因素构成的，比如用的语言、架构、处理的业务类型、数据大小等等，这是一个不断调优的过程。
首先需要确定业务类型
不同的业务会有不同的特点，有些CPU占用比较高，比如内存计算类的；有些内存占用高，比如数据处理类的；有些需要大带宽，比如网络爬虫类的；有些磁盘占用高，比如图片和数据库类的。同样配置的机器跑不同的业务，效果就会天差地别，而且未用到的***就大大的浪费了。根据自己的业务类型，调整机器的***配比，是节省资金，提高支撑能力的好办法。其次确定数据尺寸
网络传输的数据尺寸决定了带宽的占用程度，尺寸越小带宽越大，单位时间能够接入和处理的用户请求就更多。那么减少无效的数据传输，减少请求包的大小，是提高用户接入能力必须考虑的地方。***用合理的语言架构
经过良好设计的系统，和随意堆砌的系统，接入能力是完全不同的。为了解决***浪费问题，可以***用Docker之类的容器化，微服务化，能够有效的提高***使用率，减少服务器压力。***用Nginx或Tengine、开启NIO、开启压缩、以及设置静态和局部缓存等，降低服务器负载***用MongoDB、NoSQL数据库，降低数据查询压力提高响应速度....总之一句话：尽力减少前端无效请求，后端尽力将请求在靠近用户侧解决掉，避免业务过长，堆积在后端底层。不断测算和调优
支撑的TPS数，是需要不断监控不断调优的。很多时候，一个微小的参数调整，都能带来成倍的性能提高。一个数十秒的业务请求，也许调优后就能在几十毫秒完成。真正的线上服务，持续监控和持续调优是长期进行的。♥♥♥♥♥ 请任性点赞，谢谢关注 -- 我是 极迭代 ，我为自己带盐 :)
这方面我还是有一定发言权的，我自己就用阿里云的ECS将近5年了，你所说的这款4核心8G内存的配置我们隽永东方***正是用的这款配置，当然我们目前***用的是ecs+rds架构，文件服务器和数据库服务器彻底分开，这样的好处就是数据库请求不占用此ECS的***。
可以大概预测到的是这款配置还是相对较高的配置，以我们***来说，每天大概500ip，PV大概3000左右，同时在线人数最多不会超过50人吧，这种流量相对一个企业站来说还算可以，这个服务器完全可以符合要求，目前运行了相当长时间，服务器没有出现过任何中断，截取Alexa的排名数据仅供参考：
从上方数据看得出来，显示的速度是Fast，这个速度得分获得Fast可不容易，我看过好多大型的***都经常获得的得分只是中等速度，当然Alexa只是一个参考工具，并不是非常准确，但至少可以侧面反应当前站点运行的健康状况。
我们***目前***用的是WDCP控制面板下的LNAMP架构，搭载Godaddy SSL，nginx负责前端静态页面，apache负责后端动态解释，整体性能基本是一个非常稳定的状态，截图WDCP的服务器负载给大家看看：
从上图可以看出服务器负载几乎没太大负载，一般这个负载小于1就几乎不用去担心了。
因此结合我们***的运营情况，我们可以得出你这款配置的峰值并发用户应该可以到几百个用户，这里有太多因素决定同时并发数了，比如网站图片视频数量多少，数据库是否和文件服务器分开，每个用户在站点上打开的页面多少等都会影响服务器负载。
另外这些数据其实都只是一个预估的数据，显示情况远比理想状况复杂很多很多，比如你要是在这台服务器安装配置一些额外的服务，而当前服务运行的进程可能就会直接对服务器造成负载的提升等等，因此能支持多少用户这种问题本身就是一个伪命题，要具体情况具体分析，不过可以肯定的是这个配置可以支持绝大部分企业站点的正常运行相当长时间。
最后想我们的解释能给你一些有用的建议，祝你好运。
最新更新：评论里有好多人说我这个配置浪费，今天就遇到过两次负载超级高的情况，也没有任何攻击提示：
这个负载的提升是在服务器没有做任何动作的情况下进行的，类似这种时候，你们把服务器***用得很满的那种碰到这种情况如何处理？当然这种情况肯定是很极端的情况，我估计是有攻击发生，只是不明显。
谢谢大家。
[免责声明]本文来源于网络，不代表本站立场，如转载内容涉及版权等问题，请联系邮箱:83115484@qq.com，我们会予以删除相关文章，保证您的权利。转载请注明出处：http://www.pj1663.com/post/1440.html
