[undertow-dev] embedded undertow async hello world

Stuart Douglas sdouglas at redhat.com
Sun Jan 3 19:02:35 EST 2016


I am not 100% sure what you are trying to test here. I have answered your questions but in terms of providing a meaningful performance test I think the code looks pretty wrong. 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?

Stuart

----- Original Message -----
> From: "seth/nqzero" <blue at nqzero.com>
> To: undertow-dev at lists.jboss.org
> Sent: Wednesday, 30 December, 2015 3:05:05 PM
> Subject: [undertow-dev] embedded undertow async hello world
> 
> i'm doing a quick survey of java webserver performance baselines, with a
> focus on async, inspired somewhat by the Techempower plaintext benchmark.
> i've already done jetty (both sync and async), jetty-comsat (ie quasar), the
> kilim (another bytecode based fiber implementation) http server, and sync
> undertow (copied from the techempower github impl). i'd like to add an
> undertow async
> 
> for jetty i've used the servlet api for async, since i didn't see any other
> option. but i'd prefer the non-servlet api for undertow. the docs for
> undertow seem limited, esp for async. so i wanted to vet my solution. i'm
> more interested in being canonical than squeezing the last bit of
> performance (because eg: all the solutions are plenty fast, it's a terrible
> benchmark, ease of implementation is a bigger factor than absolute
> performance)
> 
> open to any general comments, but specifically wondering:
> - is my use of dispatch() correct

This is correct.


> - do i need to be calling isInIoThread()

No, as you are not doing any blocking work.

> - is it safe to access the exchange directly in reply() ? ie, in a
> non-undertow thread

In general yes, as long as you don't start modifying it in an Undertow thread at the same time. Your code should be changed to:

exchange.dispatch(SameThreadExecutor.INSTANCE, () -> store(exchange));

This means the Undertow thread won't be published to another thread until after the Undertow thread has finished working with it.

> 
> this is a somewhat simplified example that gets 75-80k req/s vs 85-90 for the
> more verbose version, but the use of the async api is the same
> 
> 
> ____my code is below___
> 
> import io.undertow.Handlers;
> import io.undertow.Undertow;
> import io.undertow.server.HttpHandler;
> import io.undertow.server.HttpServerExchange;
> import io.undertow.util.Headers;
> import java.nio.ByteBuffer;
> import java.util.Timer;
> import java.util.TimerTask;
> 
> public final class UtowAsync implements HttpHandler {
> 
> public static void main(String[] args) throws Exception {
> Undertow.builder()
> .addHttpListener(9097,"0.0.0.0")
> .setHandler(Handlers.path().addPrefixPath("/hello",new UtowAsync()))
> .build()
> .start();
> }
> 
> int num = 0;
> HttpServerExchange acv[] = new HttpServerExchange[10000];
> byte [] bytes = "hello world".getBytes();
> ByteBuffer buf = ByteBuffer.allocate(bytes.length).put(bytes);
> { buf.flip(); }

> 
> synchronized void store(HttpServerExchange async) {
> if (async==null) while (num > 0) {
> reply(acv[--num]);
> acv[num] = null;
> }
> else acv[num++] = async;
> }
> 
> void reply(HttpServerExchange exchange) {
> exchange.getResponseHeaders().put(Headers.CONTENT_TYPE, "text/plain");
> exchange.getResponseSender().send(buf.duplicate());
> }
> 
> public void handleRequest(final HttpServerExchange exchange) throws Exception
> {
> store(exchange);
> exchange.dispatch();
> }
> 
> {
> new Timer().schedule(new TimerTask() { public void run() {
> UtowAsync.this.store(null);
> } },10,10);
> }
> }
> 
> 
> _______________________________________________
> 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