Hi Stuart, I've followed undertow benchmark on Techempower's Benchmark page almost 2 years and I've noticed that undertow's benchmark code has not been updated since last year. I'd like to know what are your tips to improve Undertow's performance on TE Benchmark. Regards _______________________________________________ undertow-dev mailing list undertow-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/undertow-dev

Something else to keep in mind is that you can't really compare Undertow to rapidoid directly. The rapidoid benchmark is operating at a much lower level than Undertow does (if you look at the code you will see that they are basically manually writing headers and content to the output buffer). This is great for writing really fast benchmarks, but sucks in the real world. Just on the output side Undertow has to do a lot more work, just off the top of my head: - Creating a data structure to hold the headers (when you are handling millions of req/sec every allocation has a measurable cost) - Iterating the above data structure to build a response - Handling all the special case that go with the above, such as when the headers are two big to fit in one buffer All this is highly optimized, but it is obviously slower than simply not having to do it. Stuart On Fri, Apr 8, 2016 at 4:52 AM, Miere Teixeira <miere.teixeira(a)gmail.com&gt; wrote: > Hi Stuart, > > I've followed undertow benchmark on Techempower's Benchmark page almost 2 > years and I've noticed that undertow's benchmark code has not been updated > since last year. > > I'd like to know what are your tips to improve Undertow's performance on TE > Benchmark. > > Regards > > > _______________________________________________ > undertow-dev mailing list > undertow-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev _______________________________________________ undertow-dev mailing list undertow-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/undertow-dev

On Apr 7, 2016, at 8:51 PM, Michael Hixson <michael.hixson(a)gmail.com&gt; wrote: As far as updates to the benchmark code itself, it should probably be upgraded to the latest version of Undertow, but I don't see any optimizations to make in the handler classes etc. Trying the rapidoid approach with that code would be a mistake, in my opinion. Right now the undertow implementation is understandable and high-level enough that someone could look at it and say "Yeah, I could write a real application like that." And it's still sitting near the top of the charts. Related -- some ASP.net devs talking about the benchmark and undertow specifically as inspiration for their own performance improvements: https://youtu.be/7O81CAjmOXk?t=16m40s -Michael > On Thu, Apr 7, 2016 at 5:15 PM, Greg Hellings <greg.hellings(a)gmail.com&gt; wrote: > To be fair, that's exactly what the TE benchmarks are supposed to > show. The relative overheads of each framework/solution combination. > > So if it show that Undertow is slower than solutions that are not > frameworks, then it's showing exactly what it is supposed it! > > It is up to the reader to look at those results and understand the > merits of a full, heavy framework (like Play) or a minimal solution > (like Undertow) or a raw solution (like rapidoid) for their project > velocity. > > --Greg > >> On Thu, Apr 7, 2016 at 7:05 PM, Stuart Douglas <sdouglas(a)redhat.com&gt; wrote: >> Something else to keep in mind is that you can't really compare >> Undertow to rapidoid directly. The rapidoid benchmark is operating at >> a much lower level than Undertow does (if you look at the code you >> will see that they are basically manually writing headers and content >> to the output buffer). This is great for writing really fast >> benchmarks, but sucks in the real world. >> >> Just on the output side Undertow has to do a lot more work, just off >> the top of my head: >> >> - Creating a data structure to hold the headers (when you are handling >> millions of req/sec every allocation has a measurable cost) >> - Iterating the above data structure to build a response >> - Handling all the special case that go with the above, such as when >> the headers are two big to fit in one buffer >> >> All this is highly optimized, but it is obviously slower than simply >> not having to do it. >> >> Stuart >> >> >>> On Fri, Apr 8, 2016 at 4:52 AM, Miere Teixeira <miere.teixeira(a)gmail.com&gt; wrote: >>> Hi Stuart, >>> >>> I've followed undertow benchmark on Techempower's Benchmark page almost 2 >>> years and I've noticed that undertow's benchmark code has not been updated >>> since last year. >>> >>> I'd like to know what are your tips to improve Undertow's performance on TE >>> Benchmark. >>> >>> Regards >>> >>> >>> _______________________________________________ >>> undertow-dev mailing list >>> undertow-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/undertow-dev >> _______________________________________________ >> undertow-dev mailing list >> undertow-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/undertow-dev > _______________________________________________ > undertow-dev mailing list > undertow-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev _______________________________________________ undertow-dev mailing list undertow-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/undertow-dev