这是一个创建于 1236 天前的主题，其中的信息可能已经有所发展或是发生改变。
背景:应用原请求方式，a->b->数据库，改成了 a->数据库，流量很大。 按道理说只是避免了 b 应用的转发逻辑，但实际上 a 应用 cpu 降了 8 个点左右，不知道是不是我带来的，所以想问 rpc 调用与直接调用数据库，有很大的差异吗？数据量大小，序列化方式什么，这些会影响 CPU 水位
 | 1 leaves615 2022 年 12 月 3 日 假设每个 IO 花费 20ms 时间，IO 等待在现代操作系统基本不消耗 CPU 资源。 序列化和反序列化是需要花费 CPU 资源，同样假设没错处理花费 10 个单位 CPU 占用。 a->b->数据库: 有两次 IO ，共计 40ms 时间，两次序列 /反系列操作，20 个单位占用。 a->数据库: 一次 IO ，计 20ms 时间，无序列 /反系列操作，0 个单位占用。 |
 | 2 bbmike253455 OP @leaves615 你的计算方式是从整体上看的，b 应用 CPU 确实减少了，但是对于 a 应用来说，之前他与 b 应用发生 rpc 调用，后来与数据库，但是对于 a 来说调用次数并没有减少，只是协议发生变化，以前是 rpc ，现在数据库的 |
| 3 leaves615 2022 年 12 月 3 日 a -> b -> db a <- b <- db a -> db a <- db |
| 4 bbmike253455 OP @leaves615 a 应用与数据库通信，也类似有序列化与反序列化的过程吧 |
| 5 leaves615 2022 年 12 月 3 日 假设有，你的场景没有去掉数据库通信，在对比场景下它是恒定的。 |
 | 6 Jooooooooo 2022 年 12 月 3 日 rpc 本身就是耗性能的操作, 至少序列化 /反序列化就是要干活的. |
 | 7 tf2 2022 年 12 月 3 日 说明你们 b 性能不行。 |
 | 8 cheng6563 2022 年 12 月 3 日 RPC 一是会增加延迟，也就是说会增加线程 /连接数等负担。二是序列化挺废性能的，尤其是你用 JSON 这类文本序列化的情况下，换用 Protocol 之类的二进制序列化方案会快很多，数据库通信应该就是用了二进制协议优化的。 |
 | 9 Macolor21 2022 年 12 月 3 日 IO 方面没有差异，主要是序列化的差别 - 数据库是：StringUtils.getBytes() - 不太清楚你这边 RPC 用什么协议，JSON ？ Protobuf ？ 对比下这两个方法的基本上就是你这边的性能差异了。 |
Select Language