[undertow-dev] Improving Undertow performance

[Jason T. Greene]

Cool. Thanks for the forward!

> On Apr 7, 2016, at 8:51 PM, Michael Hixson <michael.hixson at gmail.com> 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 at gmail.com> 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 at redhat.com> 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 at gmail.com> 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 at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>> _______________________________________________
>>> undertow-dev mailing list
>>> undertow-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev