Reintroducing Quarkus Micro Tests

[franz1981]

Given that Techempower allow to expose different flavours of the same flamework and Quarkus has a known capability of adapting itself, based on the required level of performance (see https://quarkus.io/blog/magic-control/) we're going to introduce (and re-introduce) 2 different types of Quarkus applications:

• a modularized Quarkus barebone one, which is directly using the core Vertx (+ pgclient) parts which internally are powering what Quarkus usually deliver: micro classification and Raw ORM
• a refreshed Reactive-Routes + pgclient variant similar to Improved the Quarkus benchmark and added a pgclient variant #5728: fullstack classification, but Raw ORM

The plan is to have a nightly run on the Techempower CI and decide if remove/simplify again any of them, maybe renaming the existing one to better drive users into what each version actually do/what is meant for.

[franz1981]

@NateBrady23 I'm waiting @Sanne to take a quick look: I'll change the naming of these new tests later or now depending the review

[franz1981]

Moving it in draft so I can change/improve the naming

[Sanne]

LGTM - haven't benchmarked it but I guess we can see the nightly results ;)

[franz1981]

@Sanne i could bring in the enhanced update one for both pgclient and muggle, although I admit it complicate quite a bit the code (so you have the commit?)

[Sanne]

sure, why not

[franz1981]

These are the whole number of test with the names which would appear on Techempower dashboard:

• Quarkus, JPA
• Quarkus, Hibernate Reactive
• Quarkus, PostgreSQL
• Quarkus, Vert.x

@geoand @Sanne ^^

The last 2 are classified as "Raw" ORM, but Quarkus, PostgreSQL is classified fullstack (because it uses all the fancy things of quarkus to drive the requests, decorate them etc etc), while the latter is Micro, because it just uses configuration parameters injection and bean management, routing the requests itself.

[Sanne]

why "JPA" ? We're not using the this API but the Hibernate one

[franz1981]

@Sanne fair point, just wanted a short name easier (in term of char-count, really) for users: for us the only name is the maven module/docker one (which report everything).

if ORM works better is fine for me, is still short - if you have strong preference for using Hibernate I can switch it back too, and see how it looks (i'm going to do like that actually)

[dstepanov]

Guys, what is the point of having Quarkus Vertx when you only use dependency injection from Quarkus? To be fair, call it Vertx.

[franz1981]

@dstepanov
Quarkus is flexible enough to have different parts of it enabled/disabled (see https://quarkus.io/blog/magic-control/) and is built on vertx (at its very core): not only, we take care to classify these reintroduced tests in the fairest way according to the Techempower classifications (eg no ORM etc etc).

[dstepanov]

The composite score will show just the raw Vertx performance labeled as Quarkus, not touching anything around Quarkus. What is the point of it?

My personal opinion is that the code should be written as closely as you would recommend it to be in real life.

[geoand]

Both scenarios are real world scenarios.
If there were a notion of weights, then for sure the full blown scenario would be assigned a higher one.

[franz1981]

The fact that everything goes under composite score regardless the filter(s) is a bug of techempower's UI, opened at #8621.
If the filter has worked as expected, depending on the classification and/or presence of ORM, different frameworks should be reported: currently the composite score seems bugged, as reported, while the individual tests ones, nope (but need an additional click on chrome, after applying the filters).

As @geoand said all the cases are real worlds ones, in term of component choice, and given that we had no ORM reactive version in the past, it seems natural to me to have them back now.