我最近开始了一系列关于使用FHIR资源的服务到服务通信的性能调查,以确定在以下方面花费的处理时间:
- 有效载荷通信/交换
- 序列化和反序列化有效负载
在调查过程中,我遇到了两个我不明白的结果,因此我希望RSocket开发团队的帮助。我将详细说明结果和问题。
为了确定最快的通信方式,我分析了使用两种传输协议的三种传输方式——HTTP 和 RSocket。更准确地说 - 我已经分析和基准测试:
- 使用HAPI REST 服务器和 HAPI FHIR 客户端交换 FHIR 资源
- 通过使用Web 客户端访问 Spring
@RestController
端点,使用 REST 通信交换字符串(序列化 FHIR 资源)RestTemplate
- 使用RSocket消息交换 FHIR 资源
对前两种通信方法的分析在使用 HAPI REST 服务器交换 FHIR 资源和交换(原始)字符串有效负载(包括将这些有效负载反序列化为 FHIR 资源)之间产生了巨大差异。更准确地说 - 对于大型 FHIR 资源,HAPI REST 服务器增加的开销大约是(原始)字符串通信和反序列化所需开销的 3-4 倍。
关于两个服务之间的 RSocket 通信 - 我尝试使用两种模式来交换 FHIR 资源:
- 作为原始字符串,从 FHIR 资源序列化
- 作为原始 FHIR 资源,让 RSocket 处理序列化和反序列化
第一种方法(使用原始字符串)产生的负载交换开销几乎与 HTTP(使用 REST)通信所需的开销相似。更准确地说 - 通信开销比 HTTP 通信高几个百分比 (5-10%)。这让我感到惊讶,因为我认为 RSocket 通信开销会比HTTP 通信低得多——我至少看过一个 Spring & Netifi 演示,其中 RSocket 被宣传为“比 HTTP 快 10 倍”。
我的第一个想法是我在 RSocket 配置中做错了,因此我尝试了RSocketRequester
Spring bean 的各种配置更改,从零复制帧解码器的设置开始。但是,它们都没有在整体性能上有任何明显的改进。
我的下一个尝试是在服务之间交换原始 FHIR 资源,方法是实现 RSocket 编码器和解码器类来交换 FHIR 资源。在与 RSocket 编码器和解码器接口的实现进行了一些斗争之后,我设法在两个服务之间交换了 FHIR 资源。问题 - FHIR 资源通信的性能非常低,远低于String
s 交换的性能。
对于很长的介绍/上下文设置,我的问题/帮助请求是:我在分析中做错了什么和/或遗漏了什么,所以我没有获得 RSocket 承诺的性能优势?
我在这个Github 存储库中包含了两个示例项目(一个 RSocket 请求者和一个响应者)。最相关的类是RSocket 配置和 FHIR Bundle 编码器和解码器。
免责声明:我知道这个问题在Netifi 社区页面上会得到更好的解决。在过去的几天里,该页面无法再访问,因此这里有这么长的帖子。
先感谢您。