grpc是谷歌基于netty构建的rpc框架。与jetty的每请求线程模型相比，netty实现了一个高效的线程建模。grpc还使用协议缓冲区（protobuf）进行数据编码，这是基于字节的数据编码，被认为比json更快。所以理论上，grpc应该比dropwizard更快。
为了验证性能和可伸缩性的差异，我在两个框架中都实现了一个简单的服务。
https://github.com/ilkucuk/dropwizard-messenger
https://github.com/ilkucuk/grpc-messenger
我在我的计算机上设置了两个虚拟机，设置如下
|负载生成器|->| vm1:service1 |->| vm2:service2|
load generator创建n个线程并调用service1，然后service1调用service2来模拟阻塞调用。service2休眠100毫秒并返回，然后service1返回
负载测试的结果很奇怪，dropwizard更快。我多次运行负载测试，并且在很长一段时间内，它是一致的。
线程数为400时
grpc的平均响应时间为501毫秒
dropwizard的平均响应时间为455毫秒
这与更大的负载一致，其中调用线程数为800和1600。
另一个奇怪的结果是dw可以处理3200个同时调用线程，但grpc不能。
我使用virtualbox来设置虚拟机，我正在使用最新版本的ubuntu linux和jdk 11。
vm1（2核4 gb内存）（vm2 4核4 gb内存）我的目的是在vm1中测试服务，vm2是计算阻塞调用。
由于我的结果与理论相冲突，我很怀疑，但我花了很多时间来改进，结果没有改变。所以，要么理论有问题，要么我的方法或代码有问题。希望有人知道得更清楚。
附加说明：我实现了定制load generator，以便将同一个客户端用于重复调用（在我的示例中，一个客户端进行200次调用）。我在某个时候使用了jmeter，结果是一样的。因此，不使用负载测试框架并非缺乏。
谢谢，艾克