You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<p>Why didn’t we just link to the benchmark source code?
247
247
Historically, we’ve been deliberately vague about what we were comparing against (manners!). Sharing the source code would have made it totally obvious what the other framework was.
248
-
As well as preventing us from the sharing of the benchmark source, anonymizing the other framework had its own problems. Not sharing the framework name is polite, but it mean we’re not giving readers useful information to make an informed choice of framework.
248
+
As well as preventing us from the sharing of the benchmark source, anonymizing the other framework had its own problems. Not sharing the framework name is polite, but it means we’re not giving readers useful information to make an informed choice of framework.
249
249
Is Quarkus better? Oh yes, definitely. Better than what? Shhh, that’s a secret.</p>
<p>But the best help came from outside the Quarkus community. Our intention with the benchmark was to replicate the experience of a normal user, not to tune each framework to within an inch of its life. (There’s <ahref="https://www.techempower.com/benchmarks/#section=data-r23">TechEmpower</a> for that.) Measuring the "out of the box" performance seemed like the best route, partly because the sort of performance most people will experience by default, and also because it was most fair. Fairness was a strong goal, because otherwise, what’s the point in comparing? Our team have the skills to tune Quarkus applications to razor-sharp performance, but most of us don’t have those same skills for Spring. It’s just not in our job description. Tuning Quarkus but not Spring would clearly <em>not</em> be fair.</p>
304
304
</div>
305
305
<divclass="paragraph">
306
-
<p>But after we’d started publishing the first set of results, we were approached by people who used Spring Boot every day. They <ahref="https://github.com/quarkusio/spring-quarkus-perf-comparison/issues/108">pointed out that there were differences</a> in how the two frameworks handled open-session-in-view settings, and connection pool sizes. These differences were significant enough that we started to evaluate whether comparing the out-of-the-box behaviour actually <em>was</em> the fairest option. It turns out that open-session-in-view settings and fixing the N+1 problem didn’t make much difference to the numbers, but adjusting connection pool sizes did.)
306
+
<p>But after we’d started publishing the first set of results, we were approached by people who used Spring Boot every day. They <ahref="https://github.com/quarkusio/spring-quarkus-perf-comparison/issues/108">pointed out that there were differences</a> in how the two frameworks handled open-session-in-view settings, and connection pool sizes. These differences were significant enough that we started to evaluate whether comparing the out-of-the-box behaviour actually <em>was</em> the fairest option. It turns out that open-session-in-view settings and fixing the N+1 problem didn’t make much difference to the numbers, but adjusting connection pool sizes did.
307
307
In its default configuration, the Spring application was suffering from serious connection errors. If the client can’t connect, there’s no throughput, so the errors were lowering throughput. Eric, Francesco, and Sanne Grinovero spent a lot of time digging into the logs and profiling to work out configuration tweaks to ensure the Spring application could handle the load without errors.</p>
<p>What would Quarkus' new <ahref="guides/aot">AOT packaging</a> do for startup times? (We’re still working on that one, but I’m excited to see the answer.)</p>
377
+
<p>What would Quarkus' new <ahref="/guides/aot">AOT packaging</a> do for startup times? (We’re still working on that one, but I’m excited to see the answer.)</p>
<lastBuildDate>Wed, 04 Mar 2026 03:47:59 +0000</lastBuildDate>
8
+
<lastBuildDate>Wed, 04 Mar 2026 13:01:53 +0000</lastBuildDate>
9
9
10
10
11
11
<item>
@@ -45,7 +45,7 @@ If it&#8217;s not reproducible, it&#8217;s not trustworthy.</p>
45
45
<div class="paragraph">
46
46
<p>Why didn&#8217;t we just link to the benchmark source code?
47
47
Historically, we&#8217;ve been deliberately vague about what we were comparing against (manners!). Sharing the source code would have made it totally obvious what the other framework was.
48
-
As well as preventing us from the sharing of the benchmark source, anonymizing the other framework had its own problems. Not sharing the framework name is polite, but it mean we&#8217;re not giving readers useful information to make an informed choice of framework.
48
+
As well as preventing us from the sharing of the benchmark source, anonymizing the other framework had its own problems. Not sharing the framework name is polite, but it means we&#8217;re not giving readers useful information to make an informed choice of framework.
49
49
Is Quarkus better? Oh yes, definitely. Better than what? Shhh, that&#8217;s a secret.</p>
50
50
</div>
51
51
<div class="paragraph">
@@ -103,7 +103,7 @@ This is what I meant earlier about benchmarking requiring skill — these mistak
103
103
<p>But the best help came from outside the Quarkus community. Our intention with the benchmark was to replicate the experience of a normal user, not to tune each framework to within an inch of its life. (There&#8217;s <a href="https://www.techempower.com/benchmarks/#section=data-r23">TechEmpower</a> for that.) Measuring the "out of the box" performance seemed like the best route, partly because the sort of performance most people will experience by default, and also because it was most fair. Fairness was a strong goal, because otherwise, what&#8217;s the point in comparing? Our team have the skills to tune Quarkus applications to razor-sharp performance, but most of us don&#8217;t have those same skills for Spring. It&#8217;s just not in our job description. Tuning Quarkus but not Spring would clearly <em>not</em> be fair.</p>
104
104
</div>
105
105
<div class="paragraph">
106
-
<p>But after we&#8217;d started publishing the first set of results, we were approached by people who used Spring Boot every day. They <a href="https://github.com/quarkusio/spring-quarkus-perf-comparison/issues/108">pointed out that there were differences</a> in how the two frameworks handled open-session-in-view settings, and connection pool sizes. These differences were significant enough that we started to evaluate whether comparing the out-of-the-box behaviour actually <em>was</em> the fairest option. It turns out that open-session-in-view settings and fixing the N+1 problem didn&#8217;t make much difference to the numbers, but adjusting connection pool sizes did.)
106
+
<p>But after we&#8217;d started publishing the first set of results, we were approached by people who used Spring Boot every day. They <a href="https://github.com/quarkusio/spring-quarkus-perf-comparison/issues/108">pointed out that there were differences</a> in how the two frameworks handled open-session-in-view settings, and connection pool sizes. These differences were significant enough that we started to evaluate whether comparing the out-of-the-box behaviour actually <em>was</em> the fairest option. It turns out that open-session-in-view settings and fixing the N+1 problem didn&#8217;t make much difference to the numbers, but adjusting connection pool sizes did.
107
107
In its default configuration, the Spring application was suffering from serious connection errors. If the client can&#8217;t connect, there&#8217;s no throughput, so the errors were lowering throughput. Eric, Francesco, and Sanne Grinovero spent a lot of time digging into the logs and profiling to work out configuration tweaks to ensure the Spring application could handle the load without errors.</p>
108
108
</div>
109
109
<div class="paragraph">
@@ -174,7 +174,7 @@ Although we want the application to represent a typical usage, someone who copie
174
174
</div>
175
175
</div>
176
176
<div class="paragraph">
177
-
<p>What would Quarkus' new <a href="guides/aot">AOT packaging</a> do for startup times? (We&#8217;re still working on that one, but I&#8217;m excited to see the answer.)</p>
177
+
<p>What would Quarkus' new <a href="/guides/aot">AOT packaging</a> do for startup times? (We&#8217;re still working on that one, but I&#8217;m excited to see the answer.)</p>
<pclass="card-text"><spanclass="key">Description:</span> <spanclass="short-description">The primary objective of this working group is to develop the next version of Panache.
220
+
<pclass="card-text"><spanclass="key">Description:</span> <spanclass="short-description">The Quarkus 4 working group aims to coordinate and track all Quarkus 4-related development in a long-running effort.
<pclass="card-text"><spanclass="key">Point of Contact:</span> <spanclass="point-of-contact">@FroMage (@<strong>Stephane Epardaud</strong> on Zulip)</span>
<ahref="https://quarkusio.zulipchat.com/#narrow/channel/187038-dev/topic/WG.20-.20Panache.2ENext/with/529258261" title="Discuss about the working group"><i
<pclass="card-text"><spanclass="key">Description:</span> <spanclass="short-description">The objective of this working group is to enable Quarkus applications to run cleanly across dev/test/production modes on Java 25, with no requirement to adopt Java 25 as a baseline.
249
+
<pclass="card-text"><spanclass="key">Description:</span> <spanclass="short-description">The primary objective of this working group is to develop the next version of Panache.
<pclass="card-text"><spanclass="key">Point of Contact:</span> <spanclass="point-of-contact">@Sanne (@<strong>Sanne</strong> on Zulip) and @gsmet (@_<strong>Guillaume Smet</strong> on Zulip)</span>
255
+
<pclass="card-text"><spanclass="key">Point of Contact:</span> <spanclass="point-of-contact">@FroMage (@<strong>Stephane Epardaud</strong> on Zulip)</span>
264
256
</p>
265
257
266
258
</div>
267
259
<divclass="card-footer">
268
260
<divclass="icons">
269
261
270
-
<ahref="https://github.com/quarkusio/quarkus/discussions/49696" title="See the working group proposal"><i
262
+
<ahref="https://github.com/quarkusio/quarkus/discussions/48949" title="See the working group proposal"><i
<ahref="https://quarkusio.zulipchat.com/#narrow/channel/187038-dev/topic/WG.20-.20Java.2025.20chat" title="Discuss about the working group"><i
268
+
<ahref="https://quarkusio.zulipchat.com/#narrow/channel/187038-dev/topic/WG.20-.20Panache.2ENext/with/529258261" title="Discuss about the working group"><i
277
269
class="icon fa-solid fa-comments"></i></a>
278
270
279
271
</div>
@@ -282,28 +274,36 @@ <h2>Active working groups</h2>
<pclass="card-text"><spanclass="key">Description:</span> <spanclass="short-description">The Quarkus 4 working group aims to coordinate and track all Quarkus 4-related development in a long-running effort.
286
+
<pclass="card-text"><spanclass="key">Description:</span> <spanclass="short-description">The objective of this working group is to enable Quarkus applications to run cleanly across dev/test/production modes on Java 25, with no requirement to adopt Java 25 as a baseline.
<pclass="card-text"><spanclass="key">Point of Contact:</span> <spanclass="point-of-contact">@Sanne (@<strong>Sanne</strong> on Zulip) and @gsmet (@_<strong>Guillaume Smet</strong> on Zulip)</span>
296
293
</p>
297
294
298
295
</div>
299
296
<divclass="card-footer">
300
297
<divclass="icons">
301
298
302
-
<ahref="https://github.com/orgs/quarkusio/projects/51" title="View the working group board"><i
299
+
<ahref="https://github.com/quarkusio/quarkus/discussions/49696" title="See the working group proposal"><i
0 commit comments