Speedup test executions & Save the planet #23564
Conversation
| if (httpConfiguration.ioThreads.isPresent()) { | ||
| ioThreads = Math.min(httpConfiguration.ioThreads.getAsInt(), eventLoopCount); | ||
| } else if (launchMode.isDevOrTest()) { |
There was a problem hiding this comment.
Are you sure you want to do this in dev-mode as well?
There was a problem hiding this comment.
Because it's pretty significant difference between dev mode and prod mode
There was a problem hiding this comment.
I realize I might be missing something, but I don't expect people to perform load tests in dev mode.
On the other hand, it keeps resource usage under control when running interactive exploration sessions, possibly having multiple Quarkus based microservices running.
Other than performance aspects, I don't think it would have semantic changes that impact developer's ability to explore things?
( other than facilitating debugging by not having breakpoints hit by 100 threads )
But yeah sure I get that it's debatable, no rush. That's also why I pinged Stuart too, so at least he's aware.
We can totally start doing it for tests only.
There was a problem hiding this comment.
Yeah, I understand the rationale completely. It's always a delicate balance...
I am not totally against doing this in dev-mode, I guess I am +0 :)
|
This does bother me a bit, as it means the test environment is fundamentally different to the prod environment. There are some tests where this could make a difference, e.g. stress based tests such as https://github.com/stuartwdouglas/quarkus/blob/01bee6969efe374d4489d35189c65f34106cea87/extensions/resteasy-reactive/quarkus-resteasy-reactive/deployment/src/test/java/io/quarkus/resteasy/reactive/server/test/stress/SuspendResumeStressTest.java#L63 may perform differently with only 2 threads. I don't know if this is a good enough reason not to merge this though. |
|
If it bothers too much I can close it. But I don't think stresstests are commonly run this way? When they do they could set the (My patch is ineffective if the number of iothreads is configured explicitly)
prod is always going to be fundamentally different than "test" in such details, as we literally run code differently. And also this number of threads which I'm limiting depends on the executing machine, there's good chances that test boxes can't guarantee having the same number of cores as production and staging boxes, so I hope we're prepared for minor differences here. Just to put things in context, my machine has 24 cores. With HT that's reporting 48, which vertx duplicates further. So I'm spinning 96 threads each time a hello world endpoint needs to be tested with a single request... and the same pattern likely applies to each of you and CI building Quarkus each time. |
|
I was thinking about logging something in dev mode when this new block is reached. But in the end it would probably be just noise for most people. 🤔 |
|
Cool, thanks. I'm also curious to see if it makes any difference to CI builds :) |
|
CI has only two cores, but let's see. 🙂 |
.. and it's also very helpful when debugging locally to only have a couple threads rather than having to scroll through hundreds.