Cool. Thanks for the forward!
On Apr 7, 2016, at 8:51 PM, Michael Hixson
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:
> On Thu, Apr 7, 2016 at 5:15 PM, Greg Hellings <greg.hellings(a)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
>> On Thu, Apr 7, 2016 at 7:05 PM, Stuart Douglas <sdouglas(a)redhat.com>
>> 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.
>>> On Fri, Apr 8, 2016 at 4:52 AM, Miere Teixeira
>>> Hi Stuart,
>>> I've followed undertow benchmark on Techempower's Benchmark page
>>> years and I've noticed that undertow's benchmark code has not been
>>> since last year.
>>> I'd like to know what are your tips to improve Undertow's performance
>>> undertow-dev mailing list
>> undertow-dev mailing list
> undertow-dev mailing list
undertow-dev mailing list