[undertow-dev] embedded undertow async hello world

seth/nqzero blue at nqzero.com
Thu Jan 7 16:47:51 EST 2016


> I am not 100% sure what you are trying to test here
> The global state protected by a sync lock will not perform very well,
> and does not in any way represent the way the majority of web
applications manage their state.
>
> What sort of real world situation you are trying to simulate here?


i've written a java database engine - the sync lock is simulating this
database. initially i'm focusing on low-end VPS hosts, so i'm more
interested in efficiency than peak performance. i'm just trying to get a
baseline (as opposed to a benchmark) of what async is capable of on various
platforms

my database is (kilim) fiber-based and can handle far more concurrent
queries than the OS can support threads, so my motivation is to verify that
the web server can support a comparable number of open connections. this
isn't apples to apples - in the real case there could be many more
connections and much more delay, but this seems like a good start



here's the faster version:
https://github.com/nqzero/jempower/blob/master/utow/src/main/java/UtowAsync2.java

it still has the global lock, but does the actual processing in multiple
threads. the repository has versions for some other platforms as well
(jetty, comsat and kilim)

comparing the 3 undertow handlers
124k req/s - sync (from TechEmpower benchmark)
 92k req/s - async (reply inside lock)
118k req/s - async2 (with 3 threads)

this is on an i3, and i'm testing with ab (2 instances are required to
saturate the sync and async2 versions) at various concurrency levels
(mostly 1000 - 10000), and the TechEmpower version results in some receive
errors at lower concurrencies than the async versions

i also need an example of asynchronous usage so i can tell people how to
build a webapp using my database with undertow, so i want to be doing the
"right" things - hence the simple async version. thanks for the feedback to
my questions. if you can point me to a simpler example of async undertow
(that doesn't involve a thread-per-connection), i'm happy to use that
instead

my conclusion is that for undertow, using async adds at most an
insignificant overhead, perhaps something on the order of 5% throughput and
can be implemented easily, using the dispatch/getResponseSender pair

does this sound right to you ?

any idea how much memory is allocated for each outstanding request ? i'm
assuming it is much less than the memory needed for an OS thread (using top
i see a 40k concurrency delta -> a delta of 300M in resident memory usage,
but realize that this is a crude technique)

if you'd like to see any changes or want to add a caveat so i don't
misrepresent undertow, add a pull request or just let me know - my goal is
to advocate for async while being (reasonably) platform agnostic
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160107/b4f44bc4/attachment.html 


More information about the undertow-dev mailing list