建设主题网站的顺序是什么,vs哪个版本做网站好,自己给自己网站做seo,wordpress自动电影釆集这是一个程序猿写的第一个故事#xff0c;请各位懂行的客官静下心来#xff0c;慢慢品读。就知道我为什么要单独写一个文章来记录这次过程了#xff0c;因为实在是太坎坷了......
背景介绍 近期项目投产时遇到一个问题#xff0c;投产后在验证时发现大部分用户系统登… 这是一个程序猿写的第一个故事请各位懂行的客官静下心来慢慢品读。就知道我为什么要单独写一个文章来记录这次过程了因为实在是太坎坷了......
背景介绍 近期项目投产时遇到一个问题投产后在验证时发现大部分用户系统登录非常慢。由于没有找到具体原因。只能回退到投产前的版本。 后来通过分析生产的日志发现是登录接口中有段代码涉及到频繁切换数据源,这段代码耗时比较长。 到这里我先简单说下项目用到oracle和gbase数据库,oracle数据库和业务相关gbase数据库主要用来存在一些日志的。默认数据源是oracle。项目的一个filter里会把所有请求后台接口的相关信息记录在gbase库中另外登录接口也会把登录成功与否的情况也记录在gbase库。 比较耗时的代码就是登录接口有两处分别向gbase库不同表写日志,每次都需要先切换到gbase写完要切回oracle数据源而且这2个逻辑紧挨着。所以这里就会4次切换数据源。本次投产增加了其中一次向gbase写库还有就是本次投产filter向gbase写库的逻辑。 到这里基本所有背景交代完了。我先把这次投产向gbase写库的代码注释了。发现登录耗时确实下来了。通过工具性能压测响应时间下来了但是tps非常低不到10。这个接口优化路程才真正开始了.........
#排查过程# 第一季老子代码没问题怀疑网络节点限流 我们去掉了一次想gbase写库的逻辑也就减少了2切换数据源,还剩一次原代码就保留的写gbase库。但是发现这个写gbase还是比较耗时大概900ms左右其他业务代码耗时200ms。我就加了线程池把写gbase库的逻辑放到线程里包括2次切换数据源。按理说这时候tps会提升不少结果出人意料tps还不到10.还是很低。这里压测的都是测试环境的登录接口。并发量分别50、100、150测试人员各种并发量压测tps都是非常低。 到这里开始怀疑不是代码问题是不是pod之外的网络节点(比如F5)做了限制。为了验证这个想法我让测试人员在测试环境压测健康检查的接口健康检查接口非常简单没有数据库交互直接返回固定的字符串。竟然发现这个健康检查接口压测的tps也是不到10。这更坚定了我猜测的中间网络节点限流了。健康检查接口的tps都不到10这肯定是网络节点限流了啊。 后来通过找相关人员得到结论F5没有限制任何请求。我靠奔溃了那问题在哪啊 这时突然想起以前的一个同事给项目在filter加过一个流控。好像发现了新大陆经过了解这个流控的阈值 是每秒请求1000。我们的还不到10呢人家流控肯本限制不了我们但是还是不死心把流控的代码逻辑注释了果然tps还是很低和流控没有任何关系......... 第二季压测本地健康检查接口发现代码猫腻 网络节点没问题流控没问题。说真的不知道是哪里出问题了。一个简单的健康检查接口都tps不到10。怎么才能排除是不是网络节点的问题呢压测我本地代码同时把filter的流控的逻辑注释了还是压测健康检查接口。结果是tps还是非常低不到10。 完犊子了这个tps就跨不过10了吗 由于被压测结果震惊了却忽略了这次压测测试的目的是什么直接压测我本地tps还很低这中间可没有了任何网络节点流控也注释了那只能是我代码问题了。只要找到方向那就好说了虽然具体原因还是不清楚。 上次投产回退的代码我在filter里加了向gbase写日志的逻辑难道、或许应该是这里出问题了吧。那这个好办把filter里写gbase的逻辑放到线程池里完成你在耗时去子线程里耗时去吧别干扰我主线程。 修改代码后继续让测试人员压测我本地的健康检查接口。 结果呢结果就是tps还是不到10。我当时就原地石化了......... 第三季成也线程池败也线程池 程序猿轻易不言败我们就是踩不死的小强。 我放了个大招把filter里写gbase库的逻辑注释了继续压测我本地健康检查接口。奇迹终于出现了tps到了190左右。这就不对了为什么线程池没解决问题呢我用的线程是实现了Callable我们都知道这个线程有返回值。我们可以获取每个线程的返回结果。但是我们记录日志不需要等待返回结果。我就换了一种实现方法就是实现Runable接口这个线程就是不会返回结果。这里只讲故事不讲技术啊我就不帖想代码了如果还有不了解这些的小伙伴可以参考我以前的关于线程池的文章关于线程池我写过好几篇文章其中一篇是ThreadPoolExecutor线程池详解 把线程池相关逻辑更改后压测本地健康检查接口tps终于上来了到达200左右。既然找到问题了就继续优化我的登录接口把写gbase库的逻辑放到线程里以前登录接口的线程也是实现Callable接口都改成实现Runable接口奶奶滴以前还真不知道这两种写法差别这么大。说实话这块的知识点还真不知道以前只知道要想得到线程执行结果用Callable不需要线程结果用Runable。我就想了反正都是线程用哪个不是用就用Callable呗万一以后领导想要每个线程执行结果呢毕竟领导脑袋里想啥我们有不知道。跑偏了我们继续讲故事不吐槽领导了 登录结果代码的线程池优化后继续压测我本地的登录接口的tps到155了这个完全可以满足我们的业务需求了。毕竟是内部系统没那么大请求量。 然后就是在测试环境验证测试环境压测登录接口50并发情况下tps到190左右嗯还不错就是偶尔测试环境会慢........ 各位看官是不是认为到这里就结束了因为解决了登录慢问题tps也上来了嘛。嗯我也是这么认为的就这样我们就投产了。。。。。 第四季忽略小细节造成大隐患 路漫漫其修远兮吾将上下而求索信心满满经过这段时间折腾终于解决了这个问题。终于可以投产了.......啦啦啦啦啦 然而现实很残酷没想到打脸来的如此之快脸打的如此之响我们又双叒叕投产失败回退了..........啊啊啊啊啊。 这次投产后登录是没问题不慢了就是登录系统后首页的某些特定操作比较慢其他的大部分功能都正常。这就很奇怪如果说我这次优化失败了测试环境没问题就是生产也是就某些操作慢而已嘛怎么是我代码问题呢绝对不是。当然这是我内心的想法。 后来发现慢的操作的接口里有写gbase库什么这里也写gbase库 后来想想写也没事啊gbase是本来就是大数据的应用场景TB级别的数据查询库比oracle快多了。反正就是内心深处不认为是我代码问题这是不是程序猿的通病啊....... 通过分析生产的日志发现filter里大部分线程写gbase库的耗时达到了23s左右(幸亏我当时在线程里记录了耗时情况看了多打印日志还是比较好的要不这次问题很难发现)。那问题就明朗了gbase不抗揍啊。 这里再简单交代下项目系统登录后首页加载会调用大概20多个后端接口获取数据如果刚投产成功会存在好多用户登录验证功能一个用户登录后就调20个接口如果是50个用户同时登录就是1000次调用后台接口这时filter就会同时写gbase库1000次。所以登录后其他操作涉及到写gbase库的都比较慢。 这时候我突然想到测试环境压测时偶尔会出现某些操作比较慢由于我们的关注点一直在登录接口的tps上把这个忽略了。还有个关键点就是我们在测试环境压测是在晚上加班时压测的这时间点用我们系统的人少也没人反应只是测试人员登录测试环境发现的也是偶然现象因为并不是所有操作都慢嘛只有涉及的写gbase库的操作才会慢。也就没有当回事。 通过这次发现gbase和oracle的区别。打个比喻吧。oracle和gbase是2个剑客高手。 oracle剑客的优点是面对众多对手都是小卡拉米、菜鸟时得心应手。但是对手中有几个高手那oracle就不行了。 gbase剑客的优点是对手是多个和自己水平一样的高手这能轻松应对。但是对手是一群菜鸟那gbase就难应付了。 注这里得小卡拉米、菜鸟指的是每次和数据库交互的数据量大小。 最后终结 故事到目前为止算是讲完了还是做个总结吧。 第一线程池那块知识还是掌握不牢固比如这次Runable和Callble的两个接口除了线程有无返回值的区别前者的tps比后者要高的。 第二在进行某个接口压测时一定要站在全局考虑是否数据库能抗住是否会影响项目其他功能使用。 第三就是不要对自己写的代码太自信了。。。。。。。 哈哈细心的人是不是发现了你问题没解决啊由于业务其他原因我们暂时把filter里和登录接口中写gbase的日志逻辑先注释了。 虽然领导说先不记录日志了但是我还想研究下在向gbase记录日志的情况下怎么解决现在的问题。这里就给大家留下猜测吧我后续在把以后的故事发展在补充上。 有人会问为什么今天不写完呢因为我们今天也投产就是把相关写gbase逻辑的代码注释了当然还有其他功能投产。各位保佑我这次投产顺利吧都回退2次了在回退就拜拜了
