[undertow-dev] Improving Undertow performance

Michael Hixson michael.hixson at gmail.com
Thu Apr 7 21:50:47 EDT 2016


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


More information about the undertow-dev mailing list