The existing benchmarks were not optimal: bidirectional streaming wasn’t
fully asynchronous, limiting channel performance. Introduce a
`BenchmarkData` type to collect detailed metrics and print richer
results at the end. Also add latency measurements for unary READ and
WRITE operations.
As a drive-by add cxx20 checks in cmake.
Pick-to: 6.9 6.8
Change-Id: I56d61e4712b7fe9e5b8b52a14f84b0583094e373
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
It was missing for the grpc reference client. It's used in both clients
so simply add it to the shared header
Pick-to: 6.8 6.9
Change-Id: I568aa92f50c7b4c7a94d0226a7d4e4672863fac8
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* grpc async client now properly drains the completion queue upon
finishing
* server and clients now use the 'transport' option for setting up the
communication. The server now supports multiple listening addresses.
* Fix a "off by one" mismatch for the client RPC calls
Task-number: QTBUG-133254
Pick-to: 6.9 6.8
Change-Id: Iccbec72f77adb374f144c7cc1b9a8072fef00b5e
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Currently we're doing something manually, which, since Qt6 is a
dedicated feature. Use that instead for less error-prone disconnections
for our single-shot signals.
Lets not re-invent the wheel for something that has been (potentially
faster rather then slower) invented for this exact usecase.
We will promote the usage of Qt::SingleShotConnection, so as good
teachers we should be using it as well.
Pick-to: 6.8
Change-Id: I3b2b9f176f06d91b4d0946a38c53a4c2614c8a01
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
The use of shared pointers has potential risk of storing the
QGrpcOperation children forever and leaking in user code. The problem
is clearly in the lambda connections that we encourage to use in the
docs and examples:
auto stream = testStream(...);
QObject::connect(stream.get(), &QGrpcOperation::finished,
ctx, [ctx, stream]{...});
The above code will hold the 'stream' forever, unless user will make
the explicit disconnect in the lambda.
By using std::unique_ptr we partially solve this, or at least convince
user to solve this. When user creates lambda he knows the 'stream'
lifetime and most probably should consider that after the move, lambda
is owning the QGrpcOperation, so the need of disconnect is more clear
in this case:
auto stream = testStream(...);
auto *streamPtr = stream.get();
QObject::connect(streamPtr, &QGrpcOperation::finished,
ctx, [ctx, stream = std::move(stream)]{...});
The code becomes a bit more complicated, but it points explicitly to
the potential risk. Also it disallows to make this trick to multiple
lambdas at the same time.
Of course using the lambda context to control the QGrpcOperation
lifetime in this case is not necessary. But even if users will decide
to manage the QGrpcOperation lifetime differently, the use of
std::unique_ptr will clearly point to the ownership.
[ChangeLog][Grpc] All generated RPC methods now return std::unique_ptr
instead of std::shared_ptr. This change explicitly defines that caller
takes the ownership of the returned pointers.
Pick-to: 6.8
Change-Id: I271b91454f0c1b12b77127a7e025fa493367e279
Reviewed-by: Dennis Oberst <dennis.oberst@qt.io>
"Bidi" is the most used abbreviation to avoid the lengthy
"BiDirectional". Lets stay in sync with that and rename our
"bidir" to "bidi".
Ref: https://github.com/search?q=repo%3Agrpc%2Fgrpc+Bidi&type=code
Task-number: QTBUG-123625
Pick-to: 6.8
Change-Id: I735dd25db0343b7f5262cd93044ec93c98a0f2c3
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
It's sufficient to only provide the writeMessage(const QPM&) member. No
template magic is needed and it's more C++ish style wise.
We can still provide the pointer overload if we want to at some point.
Task-number: QTBUG-123625
Pick-to: 6.8
Change-Id: Ie068f241503487e24091c82e166f9c7d8805d247
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
The payload option accepts a size which will be used for every message
sent on the streaming RPCs.
the unique option is a flag that either lets all RPC operations run
through the same client or create a unique client for each
RPC-benchmark.
Pick-to: 6.8
Task-number: QTBUG-122554
Change-Id: Id8bd20a3d55189cd531151200cd94928259a39fa
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
The benchmark runs against an async grpc server.
The server has to be started manually and QTest is not used in order
to improve flamegraphs and performance and also to provide a common
ground for the following grpc-reference benchmark.
Fixes: QTBUG-122554
Pick-to: 6.8
Change-Id: Ib446df0eaf2006189f8fd985b1a8031da5c2e142
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>