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> 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> 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>
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