Commit Graph

11 Commits

Author SHA1 Message Date
Dennis Oberst bd1fccb26a grpc benchmarks: fix compiler warnings
Fix unused variables and add missing include

Pick-to: 6.10 6.9 6.8
Change-Id: Idc756938daa63a9cfd4d336598c7919de999a888
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2025-08-05 19:23:35 +02:00
Dennis Oberst bfb44df850 Fix and improve benchmarks
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>
2025-05-16 14:42:19 +02:00
Dennis Oberst 6ffaa636c7 Grpc benchmarks: add qelapsedtimer include to shared header
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>
2025-04-24 17:33:45 +02:00
Dennis Oberst 46238888f6 grpc benchmarks: miscellaneous improvements
* 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>
2025-03-06 16:43:49 +01:00
Dennis Oberst 3dfc6c66b2 grpc benchmarks: add ssl options and capabilities
Task-number: QTBUG-133254
Change-Id: I517d524e1d6c953791a11ba5351cdfd1b433cee2
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2025-01-30 11:29:04 +01:00
Dennis Oberst 19fca04537 Prefer the usage of SingleShotConnection
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>
2024-09-20 15:48:06 +02:00
Alexey Edelev a1b5a6dd8f Migrate to std::unique_ptr return value for all RPCs
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>
2024-08-30 12:08:46 +02:00
Dennis Oberst 6169acdef5 Rename 'bidir' -> 'bidi' to stay in line with upstream definitions
"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>
2024-08-23 12:33:12 +02:00
Dennis Oberst 584ab8849a qgrpcstream: remove writeMessage(const QPM*)
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>
2024-07-19 16:16:20 +02:00
Dennis Oberst 30969c7a74 Grpc benchmarks: add payload and unique options
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>
2024-07-11 13:09:25 +02:00
Dennis Oberst 118249d3c7 Add manual qtgrpc client benchmarks and async server
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>
2024-07-10 18:51:21 +02:00