这是一个创建于 755 天前的主题，其中的信息可能已经有所发展或是发生改变。
背景:应用原请求方式，a->b->数据库，改成了 a->数据库，流量很大。 按道理说只是避免了 b 应用的转发逻辑，但实际上 a 应用 cpu 降了 8 个点左右，不知道是不是我带来的，所以想问 rpc 调用与直接调用数据库，有很大的差异吗？数据量大小，序列化方式什么，这些会影响 CPU 水位
 |
1
leaves615 2022-12-03 15:50:26 +08:00
假设每个 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-03 16:02:33 +08:00
a -> b -> db
a <- b <- db a -> db a <- db |
|
4
bbmike253455 OP @leaves615 a 应用与数据库通信，也类似有序列化与反序列化的过程吧
|
|
5
leaves615 2022-12-03 16:17:43 +08:00
假设有，你的场景没有去掉数据库通信，在对比场景下它是恒定的。
|
 |
6
Jooooooooo 2022-12-03 16:20:59 +08:00
rpc 本身就是耗性能的操作, 至少序列化 /反序列化就是要干活的.
|
 |
7
lambdaq 2022-12-03 16:45:14 +08:00
说明你们 b 性能不行。
|
 |
8
cheng6563 2022-12-03 17:35:01 +08:00
RPC 一是会增加延迟，也就是说会增加线程 /连接数等负担。二是序列化挺废性能的，尤其是你用 JSON 这类文本序列化的情况下，换用 Protocol 之类的二进制序列化方案会快很多，数据库通信应该就是用了二进制协议优化的。
|
 |
9
Macolor21 2022-12-03 18:25:04 +08:00
IO 方面没有差异，主要是序列化的差别
- 数据库是：StringUtils.getBytes() - 不太清楚你这边 RPC 用什么协议，JSON ？ Protobuf ？ 对比下这两个方法的基本上就是你这边的性能差异了。 |
Select Language