We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
你好,有个问题咨询一下:
我遇到的问题的背景是:
我们的业务在进行慢接口排查时发现,某个接口在进行rpc调用时,下游服务处理了130ms后就返回了结果,返回的对象超过500kb,最终在mosn侧处理了超过350ms。
但是这个问题在某次发布后得到了解决,发布后该接口在mosn侧的耗时小到几乎可以忽略不计。当次发布的内容是升级了一个第三方依赖的jar包,主要是新增了一个下游服务的返回对象,这个时候mosn就不会因为找不到反序列化对象而报错。
我的猜测:
初步怀疑是MOSN在序列化时,如果找不到要序列化到的对象,会将错误对象全部打印出来,但是如果该对象很大的话,会因为打印而消耗大量系统资源,导致mosn侧耗时上升。
这个问题的结论对我们系统的稳定性建设十分重要,希望得到确定的答复,谢谢!笔芯!
The text was updated successfully, but these errors were encountered:
你应该是把 mosn 当 sidecar 在使用把,你咋在 mosn 中去序列化和反序列化 rpc 中的 body 呢?序列化和反序列化处理 body 就是非常消耗性能的
Sorry, something went wrong.
No branches or pull requests
你好,有个问题咨询一下:
我遇到的问题的背景是:
我们的业务在进行慢接口排查时发现,某个接口在进行rpc调用时,下游服务处理了130ms后就返回了结果,返回的对象超过500kb,最终在mosn侧处理了超过350ms。
但是这个问题在某次发布后得到了解决,发布后该接口在mosn侧的耗时小到几乎可以忽略不计。当次发布的内容是升级了一个第三方依赖的jar包,主要是新增了一个下游服务的返回对象,这个时候mosn就不会因为找不到反序列化对象而报错。
我的猜测:
初步怀疑是MOSN在序列化时,如果找不到要序列化到的对象,会将错误对象全部打印出来,但是如果该对象很大的话,会因为打印而消耗大量系统资源,导致mosn侧耗时上升。
这个问题的结论对我们系统的稳定性建设十分重要,希望得到确定的答复,谢谢!笔芯!
The text was updated successfully, but these errors were encountered: