Contention on io.vertx.core.http.impl.Http1xServerConnection

[Sanne]

Describe the bug

Have been profiling a sample Quarkus application under load; as load increases we have a scalability problem as the contention grows on a lock round io.vertx.core.http.impl.Http1xServerConnection:

( The above is a flamegraph created by running asynch-profiler with options -e lock )

Expected behavior

There should be no significant contention limiting scalability.

N.B. This benchmark has different scenarious: the ones which hit a fully reactive endpoint don't have any contention, the problem seems to affect endpoints which have to perform some blocking operation, in this case queries over Hibernate ORM (blocking).

[franz1981]

@barreiro

[geoand]

cc @vietj

[gsmet]

The comment at the top of the class might be interesting:

• This class is optimised for performance when used on the same event loop. However it can be used safely from other threads.
• The internal state is protected using the synchronized keyword. If always used on the same event loop, then
• we benefit from biased locking which makes the overhead of synchronized near zero.

[franz1981]

In vertx 5 this will be gone, but till that moment, we can still hit this

[Sanne]

Is anyone planning to work on this?

[franz1981]

@Sanne I asked @barreiro to investigate on it

[vietj]

I think we can accept Luis patch, indeed this code was written assuming event-loop and non blocking was mainly used.

In Vert.x 5, this has been replaced by the outbound message queue that uses atomics + batching

[Sanne]

Thanks @vietj and @barreiro ! Looking forward to it, I'm eager to test some other performance improvements and this one is a key piece of a larger plan.

Incidentally, I'm also looking forward to Quarkus using Vert.x 5...