dtm icon indicating copy to clipboard operation
dtm copied to clipboard

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

Open notlazychen opened this issue 1 year ago • 4 comments

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

notlazychen avatar Aug 08 '24 11:08 notlazychen

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

yedf2 avatar Sep 16 '24 11:09 yedf2

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

notlazychen avatar Sep 18 '24 01:09 notlazychen

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

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

yedf2 avatar Sep 28 '24 03:09 yedf2

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

notlazychen avatar Sep 29 '24 01:09 notlazychen