我有一个场景运行5000 bidiStream gRPC用户斜升2用户/秒，这是我目前的设置
val grpcConf = grpc(managedChannelBuilder(s"${url}").usePlaintext())
//.shareChannel
val settings_Result = grpc("name")
.bidiStream[RequestName, ResponseName](RelayServerGrpc.METHOD, "NameStream")
//exec scenario
exec(
httpconf.PaymentFinalizerProcess_Result
.connect
.header(metadataObject.Authorization)(s"Bearer ${metadataObject.TokenKey}")
.endCheck(statusCode is Status.Code.OK)
)
.exec(REST_API)
.exec(bidiStream_Complete)字符串
通常我会在大约1800个用户（时间戳900秒）时开始得到INTERNAL错误，但当我打开.shareChannel时，它会在900个用户（时间戳450秒）时更快地出现。我已经测试了大约3-4次的两种设置的相同场景，以确保原因是启用.shareChannel
所以我想问.shareChannel的效果，以了解更多，并改善这个脚本，请帮助我在这一点上。
1条答案
按热度按时间h4cxqtbf1#
如果使用
shareChannel，则所有虚拟用户共享相同的ManagedChannel。一个
ManagedChannel（粗略地说）对所有请求使用一个单一的TCP连接。grpc中的托管通道上有多个存根？
使用gRPC的TCP会话
共享TCP连接会降低资源消耗，因此可能会达到更高的吞吐量。如果服务器处理大量连接的能力在负载测试中并不重要，这可能很有用。
在你的例子中，你的服务器（或者负载生成器，或者网络）似乎不能在一个连接中处理大量的动态请求。没关系，只是不要使用
shareChannel选项。负载测试是更现实的方式。