Skip to content
New issue

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

发送MSG、SAGA的Payloads建议不要用string数组 #516

Open
notlazychen opened this issue Aug 8, 2024 · 4 comments
Open

发送MSG、SAGA的Payloads建议不要用string数组 #516

notlazychen opened this issue Aug 8, 2024 · 4 comments

Comments

@notlazychen
Copy link

notlazychen commented Aug 8, 2024

使用http prepare msg的时候,本来要传的是一组对象,但是因为request.payloads是[]string,所以得先一步序列化payload为字符串,再整个request序列化为json,中间出现了临时的string。当payload是大对象的情况下会产生中间的大字符串,压力GC。
而payload本身透传也不在乎类型,所以能否payload不要使用string,用object(interface{})?

@yedf2
Copy link
Contributor

yedf2 commented Sep 16, 2024

对于使用分布式事务的应用来说,通常瓶颈不在这个序列化和反序列化这里,所以你担心的这个问题,最好是有真实压力出现时,再考虑优化。
另一个方向是,当序列化和反序列化的压力比较大是,建议grpc,因为grpc是二进制协议,序列化和反序列化会更高效

@notlazychen
Copy link
Author

我的问题其实不是序列化的性能问题而是为了序列化而产生的大字符大对象的问题。因为要透传的数据很大,所以就发现有巨大的字符串常驻在托管堆中。

@yedf2
Copy link
Contributor

yedf2 commented Sep 28, 2024

从高维度的设计来说,payloads是每个分支的payload,在http协议里面,会按照每个payload分开保存到DB里,所以从client就分开序列化并传送是很自然的。而特意优化,减少一个中间过程,看起来是更复杂的设计。

“因为要透传的数据很大,所以就发现有巨大的字符串常驻在托管堆中。”这个会有具体什么问题吗?目前看go的垃圾收集好像没有太大的问题

@notlazychen
Copy link
Author

是dtm的C#客户端。
因为C#客户端中定义的dtmRequest的model中Payload类型是string,所以要透传一段数据时候需要把payload object->string->stream多了一个string的大对象,C#的gc几乎不会回收它。如果可以减少这一步的string,实现payload零拷贝直接写入到httpClient发送的缓冲区的话就好了,也就是object->stream。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants