如何估算Linux服务上的QPS

2021/08/09

前言

​ 我目前任职的是一家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的常规操作了

image-20210809174843179

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

image-20210809175724505

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

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

image-20210809180219034

前面是数字,后面是每一秒

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

image-20210812121109685

我的日志格式

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

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

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

后言

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

(转载本站文章请注明作者和出处 没有气的汽水



┌┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┬┐
├ 文章已经完啦, 想要第一时间收到文章更新可以关注↓ ┤
└┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┴┘

Post Directory






下面是评论区,欢迎大家留言探讨或者指出错误哈