[kotlin/vertx-web-kotlin-dsljson] Mark tests as stripped

[joanhey]

FrameworkBenchmarks/frameworks/Kotlin/vertx-web-kotlin-dsljson/src/main/kotlin/com/example/starter/helpers/PeriodicResolver.kt

Lines 17 to 18 in d36a2ed

	private val PLAINTEXT_CONTENT_LENGTH: CharSequence= HttpHeaders.createOptimized(DefaultHandler.MESSAGE.length.toString())
	private val JSON_CONTENT_LENGTH: CharSequence = HttpHeaders.createOptimized(MessageHandler.DEFAULT_MESSAGE.serialize().length().toString())

FrameworkBenchmarks/frameworks/Kotlin/vertx-web-kotlin-dsljson/src/main/kotlin/com/example/starter/helpers/PeriodicResolver.kt

Lines 46 to 60 in d36a2ed

	private fun nextPlaintext(): MultiMap = HttpHeaders
	.headers()
	.add(HttpHeaders.SERVER, SERVER)
	.add(HttpHeaders.DATE, current)
	.add(HttpHeaders.CONTENT_TYPE, CONTENT_TYPE_TEXT_PLAIN)
	.add(HttpHeaders.CONTENT_LENGTH, PLAINTEXT_CONTENT_LENGTH)
	.copy(false)
	private fun nextJson(): MultiMap = HttpHeaders
	.headers()
	.add(HttpHeaders.SERVER, SERVER)
	.add(HttpHeaders.DATE, current)
	.add(HttpHeaders.CONTENT_TYPE, CONTENT_TYPE_APPLICATION_JSON)
	.add(HttpHeaders.CONTENT_LENGTH, JSON_CONTENT_LENGTH)
	.copy(false)

@awmcc90

[joanhey]

Too many frameworks (specially in java and kotlin) have 2 permutations only to separate json/plaintext from the database calls.

If we prohibit that, we can have faster runs and more realistic results.

[awmcc90]

There won't be any impact on the results but I'm fine with merging the two into one to decrease overall run time. You can cancel this PR and I'll raise one that merges the two.

[joanhey]

This PR is not about merge both permutations, that it will help a lot to have faster runs.

It's about the Content-Length header, that is not generate it for each request, as is using a constant (so only calculate the length one time) not for each request.

[joanhey]

When you fix the Content-Length to be generate for each request, you can mark the test as Realistic again.

[awmcc90]

Yeah, I don't approve of this change. You'll need to update this PR to make the appropriate changes across all benchmarks that do the same prior to that.

[joanhey]

Help with the java frameworks than do the same, Java is not my best language.

Other PRs similar to this one:

• [java/vertx] Mark tests as stripped #10658
• [swift/swift-nio] Mark tests as stripped #10657
• [c#] Mark Unhinged tests as Stripped #10643
• [rust/ntex] Mark all plt tests as stripped #10642
• ....

[ruroru]

Yeah, I don't approve of this change.

Approving or no "private val JSON_CONTENT_LENGTH: CharSequence = HttpHeaders.createOptimized(MessageHandler.DEFAULT_MESSAGE.serialize().length().toString())", looks a bit much. When it comes to PR, I think just marking it as stripped will do no good (as i mentioned in another PR), a nicer solution would be inlining the value, and it will do little to no harm.

You'll need to update this PR to make the appropriate changes across all benchmarks that do the same prior to that.

Got to start somewhere. There is no reason to be overly attached to something that little. Eventually all frameworks will be fixed

[joanhey]

Java is not my language, and the time spend for fix it is from the initial dev that create it using tricks.
I don't have enough time.

[awmcc90]

I'm supportive of improving the quality of the benchmark results overall. But the right way to do that would be to raise a meta topic on the subject to be get broader alignment. Then make changes to the wiki outlining the expectations for each tests and what qualifies / disqualifies implementations. And then after that, notify the owners / give some window to update. And I would include in that other things like imposing a maximum build time, merging all implementations into one docker container, etc.

[joanhey]

Merging the implementations into one docker container is a comment that I made, and not approved .
But it'll be beneficial for all the time spent now in each run.

[awmcc90]

Yeah I agree with you, its a good idea and should be done. I plan on making that change.

[joanhey]

JSON Serialization
The JSON Serialization test exercises the framework fundamentals including keep-alive support, request routing, request header parsing, object instantiation, JSON serialization, response header generation, and request count throughput.

We need to generate the headers, not hard coded or with constants.

[p8]

I'm supportive of improving the quality of the benchmark results overall. But the right way to do that would be to raise a meta topic on the subject to be get broader alignment.

This issue has been raised before:
#10611 (comment)
#10624 (review)
#9916 (comment)
#8205
#9440
#9578

[joanhey]

Fixed in #10664

[joanhey]

Reopen again @msmith-techempower

[awmcc90]

Why was this merged? It was resolved in #10664.

[msmith-techempower]

Apologies - @joanhey reopened it and I got confused in the merge order. I'm reverting with #10778

[awmcc90]

No worries, thanks for the update!