文章目录
一、qps是什么
QPS
QPS即每秒查询率，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。
每秒查询率
因特网上，经常用每秒查询率来衡量域名系统服务器的机器的性能，即为QPS。
对应fetches/sec，即每秒的响应请求数，也即是最大吞吐能力。
计算关系：
QPS = 并发量 / 平均响应时间
并发量 = QPS * 平均响应时间
二、 TPS是什么
TPS：Transactions Per Second（每秒传输的事物处理个数），即服务器每秒处理的事务数。TPS包括一条消息入和一条消息出，加上一次用户数据库访问。（业务TPS = CAPS × 每个呼叫平均TPS）
TPS是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。
一般的，评价系统性能均以每秒钟完成的技术交易的数量来衡量。系统整体处理能力取决于处理能力最低模块的TPS值。
例如：天猫双十一，一秒完成多少订单
三、QPS与TPS的区别是什么呢？
举个栗子：假如一个大胃王一秒能吃10个包子，一个女孩子0.1秒能吃1个包子，那么他们是不是一样的呢？答案是否定的，因为这个女孩子不可能在一秒钟吃下10个包子，她可能要吃很久。这个时候这个大胃王就相当于TPS，而这个女孩子则是QPS。虽然很相似，但其实是不同的。
四、如何提高单机qps
1、机器本身
1.1、cpu
1.2、内存
1.3、IO
1.4、网络
2、程序代码
3、逻辑架构
五、机器本身
分析的整体方法是由浅入深、层层深入，先看服务器本身的指标有没有遇到短板，这个层面的分析也是相对最容易的，在配置层面（ulimit相关例如fd等）检查没有问题后，从下面四个方面进行分析。
1、cpu
cpu粗面上看有两个指标，当前使用率和负载，使用率反应的是当前cpu使用的情况，而负载反应的是cpu任务的队列情况，也就是说任务排队情况。一般cpu使用率在70%以下，负载在0.7*核心数以下，cpu的指标就算正常。
也有例外情况得分析cpu的详细指标，在运维小米消息系统的一个模块时，服务器用的是阿里云的ecs，整体cpu利用率不到30%，但业务就是跑不上量，和肖坤同学查后发现cpu0的软中断极高，单核经常打到100%，继续查后发现网络中断都在cpu0上无法自动负载，和阿里云工程师确认后是所在机型不支持网卡多队列造成的，最终定位cpu的单核瓶颈造成了业务整体瓶颈，如下图：
cpu用满的解决办法简单粗暴，在程序无bug的前提下，换机型加机器，cpu本身没单独加过。
2、内存
内存常规看的是使用率。这个在做cdn的小文件缓存时遇到过，当时用的是ats，发现程序经常重启，业务跟着抖动，查日志后发现系统OOM了，当内存快要被占满的时候，kernel直接把ats的进程给杀掉，然后报out of socket memory，留的截图如下：
同样，在应用层没有优化空间时，那就加内存吧！！
3、IO
IO主要指硬盘，一般用iostat -kdx 1看各种指标，当 %util超过50%，且偶发到100%，这说明磁盘肯定是到瓶颈了。
要进一步查看是否由于IO问题造成了系统堵塞可以用vmstat 1 查看，下图b对应因IO而block的进程数量。
这个在新浪做图片业务时遇到过，是一个源站的裁图业务，设计上为了避免重复裁图，在本地硬盘上存了一份近7天的数据，由于用python写的，没有像JVM那种内存管理机制，所有的IO都在硬盘上。有一天业务突然挂了，和开发查了2个多小时未果，中间调整了各种参数，紧急扩容了两台机器依然不起作用，服务的IO高我们是知道的，查看IO数据和历史差不多，就没往那方面深考虑，后邀请经验颇多的徐焱同学参与排查，当机立断将IO处理逻辑由硬盘迁到内存上，IO立马下来了，服务恢复。
IO问题也得综合的解决，一般从程序逻辑到服务器都要改造，程序上把重IO的逻辑放在内存，服务器上加SSD吧。
4、网络
网络主要是看出、入口流量，要做好监控，当网卡流量跑平了，那么业务就出问题了。
同样在运维图片业务时遇到过网卡跑满的情况，是一个图片（小文件）的源站业务，突然就开始各种5XX告警，查后5XX并无规律，继而查网卡发现出口流量跑满了，继续分析，虽然网卡是千兆的，但按理就cdn的几个二级回源点回源，不至于跑满，将文件大小拿出来分析后，发现开发的同学为了省事儿，将带有随机数几十M的apk升级包放这里了，真是坑！！
网卡的解决方式很多，做bond和换万兆网卡（交换机要支持），当前的情况我们后来改了业务逻辑，大于多少M时强制走大文件服务。
六、程序代码
当查了cpu、内存、IO、网络都没什么问题，就可以和开发好好掰扯掰扯了，为什么服务器本身没什么压力，量却跑不上去，不要以为开发写的程序都很优良，人无完人何况是人写出来的程序呢？
很多时候就是程序或框架本身的问题跑不上去量，这个过程运维还是要协助开发分析代码逻辑的，是不是程序cpu和内存使用的不合理？是不是线程池跑慢了？是不是用的同步没改异步？要把代码执行的所有逻辑环节一一分析，找出瓶颈点，解决掉，常用的方法是日志埋点或者用专业的apm工具做钻取分析。
如果暂时不好解决，可以考虑是不是可以跑一下多实例。
七、逻辑架构
发展至今，微服务架构设计已成为大型互联网应用的标配，各模块间通过HTTP、RPC等相互依赖调用，如果查完服务器、程序依然没有问题，再往深处走就得协同开发分析系统架构了，这也是微服务系统下的一个特色，不是因为服务器或者程序本身bug造成了业务瓶颈，而是某个模块的短板造成了整个业务吞吐量上不去，这个很好理解，模块中甚至有很多接口用的是公网外部服务，慢是正常的。
具体分析上，从一次完整的请求分析一遍所有模块调用，从头到尾理一遍外部依赖的上下游资源和调用关系，外部资源包括api接口、DB、队列等，然后在每个点做埋点日志，将数据进行分析，我们在线上用这种方法不知道分析出了多少瓶颈。
如果某个模块没有做好降级熔断，再加上程序的执行是堵塞的，一个模块慢拖累整个请求，进而QPS上来后拖夸整个系统的例子很多，在这种情况下，如果瓶颈模块依赖的接口是别的部门或外网资源，加多少服务器都解决不了问题，进行改造吧。
6233
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
