高校门户网站建设,大图网,app制作企业,网站建设的内容是什么问题描述
前情提要#xff1a;一个go服务使用了公司内部的流式框架#xff0c;将业务拆分成算子#xff0c;算子间通过Input和output进行参数传递 线上一个go模块会有偶现的非预期错误#xff0c;通过日志发现是出现了算子入参的丢失#xff0c;首先怀疑是不是自己的框架…问题描述
前情提要一个go服务使用了公司内部的流式框架将业务拆分成算子算子间通过Input和output进行参数传递 线上一个go模块会有偶现的非预期错误通过日志发现是出现了算子入参的丢失首先怀疑是不是自己的框架打开方式错了排查后发现不是再排查是不是框架问题这怎么可能要是内部框架有这种问题厂内早爆炸了 后通过补充日志观察到是中间某个算子执行超时了导致出现了上述问题 你问我为啥代码会超时 我只想说不可能 绝对不可能 但是问题终归要解决于是开始排查程序的性能问题
解决过程
go tool pprof http://localhost:8020/debug/pprof/profile?seconds1500上述命令结束后会产出一个文件go tool pprof -httpIP:PORT 你自己的文件路径浏览器会打开一个火焰图看下哪些是业务的代码火焰图就是看顶层的哪个函数占据的宽度最大。只要有平顶plateaus就表示该函数可能存在性能问题。颜色没有特殊含义因为火焰图表示的是 CPU 的繁忙程度所以一般选择暖色调。如果有平顶那就尝试优化吧朋友 官网更全的信息参考这里https://pkg.go.dev/net/http/pprof
排查结论
存量代码在算子中的耗时主要集中在数据解析时取巧的使用了json序列化和反序列化简单字符串的拼接使用了fmt.sprintf 优化后长尾耗时数量明显下降明显
