does this ring a bell for anybody?

# spring

[xii]

does this ring a bell for anybody?

[sdeleuze]

If this is using blocking operations may be the cause. use https://github.com/reactor/BlockHound to check.

[xii]

i'll give it a try, thank you!

[xii]

good call, pretty much every request is blocking somehow

[xii]

but the stack trace is not very intuitive

[xii]

because all blocks seem to ocme from

at java.base/java.lang.Thread.run(Thread.java:835)

[xii]

and ends up in a ReadBytes, which is strange because I'm never reading files

[Jacob]

Are you generating any UUIDs? I seem to remember hearing that that's a blocking op

[xii]

no! but after investigating a bit more, I noticed that its coming from a SSLContext call from dynamodb async client

[sdeleuze]

Probably worth to create a related issue in their bugtracker to see their feedback.

[corneil]

For the same work on a single client you will likely see better performance on WebMVC than WebFlux. If you hit a simple server with a 1000 clients you will see WebFlux shine. I did a talk on that way back when WebFlux was first released. https://www.slideshare.net/CorneilduPlessis/reactive-spring-5-82845613
Now that I look at the slides I see that my sample included accessing MongoDB and the payoff was already apparent for a single client.

[xii]

@corneil these tests we are doing is on a big amount of clients, around 1600rps

[xii]

i managed to improve performance quite a bit by swapping AWS' dynamodb client's SslProvider from JDK's to openSSL (which was generating the GHASH.blockMult high CPU usage)

[xii]

keep in mind --- this is using kotlin + webflux, not Java

[xii]

what i noticed using Blockhound as suggested by @sdeleuze (thank you by the way, this was incredibly helpful) was that kotlin's reflective tools allllll generate blocks, on every single request

[xii]

you can use kotlin's reactor debug to ignore them, but the problem prevails. I believe this slows it down in comparison to just using java

[xii]

but in general, after swapping ssl provider the results are very comparable

[corneil]

SSL session setup may be a huge penalty if the implementation isn't reactive.

[xii]

from my tests with blockhound, it would seem to be a reactive implementation

[xii]

just very cpu intensive for some reason

[xii]

in comparison to openSSL's

[sdeleuze]

For the Kotlin reflect blocking calls please vote and follow https://youtrack.jetbrains.com/issue/KT-46071.