希望你做得很好，我有一个小问题，挂在这里。
我在REST和gRPC（bidiStream类型）之间有一个交互，如下所示：gRPC将调用以启动会话，然后我将REST转换为一个responses '将待机（粗略地说，这意味着加载），直到gRPC再次调用以抛出响应，我已经编写了一个脚本，如下所示
exec(
fromClientSide
.connect
.header(metadataObject.Authorization)(s"Bearer ${metadataObject.TokenKey}")
.callOptions(CallOptions.DEFAULT.withDeadlineAfter(30, TimeUnit.SECONDS))
.endCheck(statusCode is Status.Code.OK)
)
.exec(
fromClientSide
.send(WarmUp_Msg)
)
.pause(200)
.exec(
REST_API_HERE
)
.during(2){
exec(
fromClientSide
.send(request_Msg)
)
.exec(complete)
}
.exec(fromClientSide.reconciliate(waitFor = NextMessage))字符串
正如我理解你的例子中的during（），我看到你可以触发chatCall发送一个新的包，我想我做了同样的事情，但我不确定为什么REST API一直运行而不是抛出响应。
那么，如何实现两者之间的这种互动呢？
1条答案
按热度按时间g6baxovj1#
我很难理解你的问题描述。我猜你的HTTP调用只会在流完成（或流中的某些消息）后返回。
这听起来像是鲁布·戈德堡机器
在一系列的操作中，Gatling中的虚拟用户会一个接一个地完成这些操作。用伪代码重写Gatling代码：
字符串
我希望现在很明显，伪代码的第7行在第4行完成之前不会执行。
换句话说，
fromClientSide.send(request_Msg)在REST_API_HERE完成之前不会被执行。换句话说，您正在寻找一种在Gatling中启动HTTP请求而不“阻塞“1虚拟用户的方法，然后虚拟用户在gRPC流中发送消息。
不支持此用法。2
你可以尝试用两个虚拟用户来模拟，一个进行HTTP调用，另一个进行流式gRPC调用。
或者更好的是，消除后端设计中的复杂性。
1 Gatling的“非阻塞”特性是线程不会被IO阻塞。
2我不是说这是不可能的，只是不支持。