如何估算Linux服务上的QPS

前言

	我目前任职的是一家toC端的互联网公司，toC端意味着服务直面用户，任何一个线上小小的问题都会无限的被放大，虽说线上的考验非常残酷，但是每每发版以后看到刷刷刷的日志，心里确实很有成就感，这也是我非常热爱toC端开发的原因。

	说来也羞愧，公司曾经也辉煌过，趁着原来疫情大家都在隔离加上运营同学相当的给力，曾经日活高达200w-300w，据同事说哎呀当时那个流量打过来，原来在书上看的各种方法都没有，最终还是加机器解决问题。首页接口QPS高达4000-5000。虽然随着疫情的好转，我们并没有抓住这个机会发展下去，但是也有了一定的口碑，现在流量非常平稳，并且潮汐性高峰(因为K12群体，白天要上课，晚上和周末可能时间多一些)。日活稳定在20W-30W之间，周末和上新版本波动会大一些。新增和留存不管怎么折腾都没什么比较大的增幅，但是不会衰减。

	最近在面试嘛，简历自然要展现一下自己的实力，描述了一下我们曾经的辉煌时刻，面试官听了4k的QPS感觉会更有话聊一些，但谁都不想总沉迷于过去，难免会问一下现在的QPS情况...这一下就把我问蒙了，因为平时我接触数据比较多，比较关切的是日活和新增。QPS现在没有特意去看，只能遗憾的说不太清楚，只能告知现在的日活。

	所以现在就查一下，目前我司我负责的最高接口QPS调用情况，大家也可以参考我的去自己生产试试，如果你也是toC端的开发者，我觉得你也应该适当关注一下。

	**值得注意的是，我是通过日志来估算出单台结点查询次数(因为每次调用接口会打日志)，演示接口只是APP中的一个二级功能(虽然原来是首页接口)，所以不代表公司整体实力，只是一个部门的一个单节点的接口而已。**

这边也简单介绍一下QPS的概念

QPS（Query Per Second）：每秒请求数，就是说服务器在一秒的时间内处理了多少个请求。

估算QPS

既然是请求次数，我就可以通过日志来估算，因为我的日志每次都会把入参打出来方便定位线上问题，日志自然是有时间嘛，那我可以通过日志来计算我的服务在这台机器上面QPS情况。

1. 先找到对应的日志所在路径，我的服务是使用LSB负载均衡物理机搭建的，日志切分按照时间，所以看起来可能有点多，实时日志会不断append到非文件夹的三个log文件里面，然后按照时间切分到不同的文件夹，log4j的常规操作了

1. 使用tail -f info.log来查看一下接口的实时日志，其中-f表示follow实时查看

1. 然后我们挑选一个调用最高的接口来估算该接口的QPS，注意这个接口应该每次请求只打一次日志，如果你打了两次可能会导致估算不准确。这里我使用RecommendServiceImpl这个调用来估算整体情况

2. 然后把日志都放到管道里面过滤出要统计的日志信息，最后裁剪出时间然后统计，可以看到统计结果平均在80左右

图中用到的命令是tail -f info.log | grep RecommendServiceImpl | cut -f1 -d'.' | uniq -c 每个打的日志格式不一样，所以需要理解一下里面的意思

其中grep RecommendServiceImpl是过滤出要测的接口

cut是截取一下时间，其中-d‘.’表示字符串风格表示符号，单引号里面的就是分割符，例如因为我日志是有打毫秒值的，所以我根据.来分段，-f1表示我要取分段以后的第一段(从1开始数)，同理-f2就是第二段也就是.后面这部分，

uniq显示或者忽略重复的行，但是加上-c就可以累计相同行数，所以我们这边累加起来

后言

当然这样只是估算，能让自己心里有个数，因为不同的业务时间接口请求是不一样的，尤其例如是我K12场景下潮汐流量场景，还有哦，我这只是单节点在物理机上看一下，如果想要了解真实流量情况还是应该在网关层面看，当然例如我们主服务是搭建在SAE的Serverless上的，阿里提供很多指标来展示服务流量情况，真实数值会远比这大得多。