From tomaz.cerar at gmail.com  Mon Jul  3 10:13:30 2017
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Mon, 3 Jul 2017 16:13:30 +0200
Subject: [undertow-dev] questions about undertow.js
In-Reply-To: <002101d2ee7b$0c6a5910$253f0b30$@out-side.nl>
References: <000e01d2ee79$4ac6ed10$e054c730$@out-side.nl>
	<002101d2ee7b$0c6a5910$253f0b30$@out-side.nl>
Message-ID: <CAMquZP6pkhXxNjvbBMXXncC5d2n2KLo3N5GmaehtnAZ83oz4qw@mail.gmail.com>

Hey,

you can ask here or on WildFly forum https://developer.jboss.org/en/wildfly

Did you try with this QS?
https://github.com/wildfly/quickstart/tree/11.x/kitchensink-utjs-angularjs

Also what version of WildFly / Undertow are you using?

--
tomaz

On Mon, Jun 26, 2017 at 2:52 PM, the outsider <openindiana at out-side.nl>
wrote:

> Dear team,
>
>
>
> Is there a place where i can ask some questions regarding undertow.js ?
>
>
>
> For some reason I cannot get the POST function functioning in combination
> with angular POST requests.
>
>
>
> It must be something stupid on my side, but I am a bit lost at the moment.
>
>
>
> (I have read http://wildfly.org/news/2015/08/10/Javascript-Support-In-
> Wildfly/ but the post examples don?t work either)
>
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170703/b00f3559/attachment.html 

From senthilec566 at gmail.com  Fri Jul  7 05:44:52 2017
From: senthilec566 at gmail.com (SenthilKumar K)
Date: Fri, 7 Jul 2017 15:14:52 +0530
Subject: [undertow-dev] Undertow Http Server - Handling 2 Millions
 Requests Per Second Per Instance
In-Reply-To: <CANd+gFx4WLY54cPirYOc6PiRByY01HAKLVX0XiEEFOBmae5zxg@mail.gmail.com>
References: <CA+xmZH2ChvRWQGK4X-oFmzxdTzq7R2W7GPv0t=2VrkKDW2a6TQ@mail.gmail.com>
	<CA+xmZH1UDdugtkDvxTp9KdL_h2UtP7QRrz5As-KRj6M8W3DM1g@mail.gmail.com>
	<CALc5U3Fy1POagBsY39aMOtbFjJYRYN0SQs8cTu=jovxtxGx6DA@mail.gmail.com>
	<CA+xmZH3nLf_-JhdYGcbSpB4LzhkHSni3n+OTgj=J9WM=t1YQ6w@mail.gmail.com>
	<CALc5U3F_kYOiNsA9P28EyJM_utqm5LmmZiKusNLQQnobM0TLVg@mail.gmail.com>
	<CA+xmZH3fOcO3L6ztGiqty33jeeXeJjmjGKVqBCXzB3NdkpA2Pg@mail.gmail.com>
	<CAD+L2cw-KCPNCy-+fYheUMTMmj-7+GdAi9y568HcTWKoBX5aOg@mail.gmail.com>
	<CALc5U3HdmPTSeePwft-zc2hRELvim8Rpbr05QYaR-6prpGUo4A@mail.gmail.com>
	<CA+xmZH0OTSpTYhvk94Xt2B66-BaAFKWNNp7YbBbj4+ZQ6ZB9GQ@mail.gmail.com>
	<CAD+L2cy-w8xsu5q2y7vTQzFSy_9V9Jm1X=EaALV6QYp3dVS++A@mail.gmail.com>
	<CANd+gFx4WLY54cPirYOc6PiRByY01HAKLVX0XiEEFOBmae5zxg@mail.gmail.com>
Message-ID: <CA+xmZH12c=meg-wv982jAF-tX_5etmq66LVa0VOkB3HhM_ZL-g@mail.gmail.com>

Sorry for delay in responding to this thread!

Thanks to everyone who helped me to Optimize Undertow Server.

Here is the comparison after benchmarking my use case against Netty:

*Undertow Vs Netty :*

Test Case 1 :
Simple Request Response ( No Kafka ):

*Undertow:*
Running 10m test @ http://198.18.134.13:8009/
  500 threads and 5000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     *3.52m *    2.64m    8.96m    54.63%
    Req/Sec   376.58    103.18     0.99k    80.53%
  111628942 requests in 10.00m, 13.72GB read
  Socket errors: connect 0, read 28, write 0, timeout 2
Requests/sec: *186122.56*
Transfer/sec:     23.43MB

*Netty:*
Running 10m test @ http://198.18.134.13:8009/
500 threads and 5000 connections
Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     *3.77m*     2.10m    7.51m    57.73%
    Req/Sec   518.63     31.78   652.00     70.25%
  155406992 requests in 10.00m, 13.82GB read
  Socket errors: connect 0, read 49, write 0, timeout 0
Requests/sec: *259107*.30
Transfer/sec:     24.17MB


*Test Case 2:*
Request --> Read --> Send it Kafka :

*Undertow:*
Running 10m test @ http://198.18.134.13:8009/
500 threads and 5000 connections
Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     *4.37m *    2.46m    8.72m    57.83%
    Req/Sec   267.32      5.17   287.00     74.52%
  80044045 requests in 10.00m, 9.84GB read
  Socket errors: connect 0, read 121, write 0, timeout 0
Requests/sec: *133459.79*
Transfer/sec:     16.80MB

*Netty:*
Running 10m test @ http://198.18.134.13:8009/
500 threads and 5000 connections
Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     *3.78m *    2.10m    7.55m    57.79%
    Req/Sec   516.92     28.84   642.00     69.60%
  154770536 requests in 10.00m, 13.69GB read
  Socket errors: connect 0, read 11, write 0, timeout 101
Requests/sec: *258049.39*
Transfer/sec:     23.38MB



CPU Usage:
*Undertow:*
[image: Inline image 1]

*Netty:*
[image: Inline image 2]


--Senthil

On Thu, Jun 29, 2017 at 7:34 AM, Bill O'Neil <bill at dartalley.com> wrote:

> 1. Can you run the benchmark with the kafka line commented out at first
> and then again with it not commented out?
> 2. What rates were you getting with Jetty and Netty?
> 3. Are you running the tests from the same machine or a different one? If
> its the same machine and its using 20 threads they will be contending with
> undertows IO threads.
> 4. You can probably ignore the POST check if thats all your going to
> accept and its not a public api.
>
> import io.undertow.server.HttpHandler;
> import io.undertow.server.HttpServerExchange;
> import io.undertow.util.Headers;
> import io.undertow.util.Methods;
>
> public class DLRHandler implements HttpHandler {
>
>     final public static String _SUCCESS="SUCCESS";
>     final public static String _FAILURE="FAILURE";
>     final PostToKafka post2Kafka = new PostToKafka();
>
>     @Override
>     public void handleRequest( final HttpServerExchange exchange) throws
> Exception {
>         if (exchange.getRequestMethod().equals(Methods.POST)) {
>               exchange.getRequestReceiver().receiveFullString((
> exchangeReq, data) -> {
>                   //post2Kafka.write2Kafka(data); // write it to Kafka
>                   exchangeReq.getResponseHeaders().put(Headers.CONTENT_TYPE,
> "text/plain");
>                   exchangeReq.getResponseSender().send(_SUCCESS);
>               },
>              (exchangeReq, exception) -> {
>                  exchangeReq.getResponseHeaders().put(Headers.CONTENT_TYPE,
> "text/plain");
>                  exchangeReq.getResponseSender().send(_FAILURE);
>             });
>          }else{
>              throw new Exception("Method GET not supported by Server ");
>          }
>     }
> }
>
> On Wed, Jun 28, 2017 at 6:59 PM, Stuart Douglas <sdouglas at redhat.com>
> wrote:
>
>> The multiple dispatches() are unnecessary (well the second one to the
>> IO thread is definitely unnecessary, the first one is only required if
>> post2Kafka.write2Kafka(data); is a blocking operation and needs to be
>> executed in a worker thread).
>>
>> Stuart
>>
>> On Wed, Jun 28, 2017 at 5:42 PM, SenthilKumar K <senthilec566 at gmail.com>
>> wrote:
>> > After modifying the code below i  could see the improvement ( not much
>> > slightly ) in server - 65k req/sec.
>> >
>> > import io.undertow.server.HttpHandler;
>> > import io.undertow.server.HttpServerExchange;
>> > import io.undertow.util.Headers;
>> > import io.undertow.util.Methods;
>> >
>> > public class DLRHandler implements HttpHandler {
>> >
>> >     final public static String _SUCCESS="SUCCESS";
>> >     final public static String _FAILURE="FAILURE";
>> >     final PostToKafka post2Kafka = new PostToKafka();
>> >
>> >     @Override
>> >     public void handleRequest( final HttpServerExchange exchange) throws
>> > Exception {
>> >         if (exchange.getRequestMethod().equals(Methods.POST)) {
>> >                 exchange.getRequestReceiver().receiveFullString((
>> > exchangeReq, data) -> {
>> >                   exchangeReq.dispatch(() -> {
>> >                       post2Kafka.write2Kafka(data); // write it to Kafka
>> >                       exchangeReq.dispatch(exchangeReq.getIoThread(),
>> () ->
>> > {
>> >
>> > exchangeReq.getResponseHeaders().put(Headers.CONTENT_TYPE,
>> "text/plain");
>> >                           exchangeReq.getResponseSender().send(_
>> SUCCESS);
>> >                       });
>> >                   });
>> >               },
>> >              (exchangeReq, exception) -> {
>> >                  exchangeReq.getResponseHeaders
>> ().put(Headers.CONTENT_TYPE,
>> > "text/plain");
>> >                  exchangeReq.getResponseSender().send(_FAILURE);
>> >             });
>> >          }else{
>> >              throw new Exception("Method GET not supported by Server ");
>> >          }
>> >     }
>> > }
>> >
>> >
>> > Pls review this and let me know if i'm doing anything wrong here ...
>> > --Senthil
>> >
>> > On Fri, Jun 23, 2017 at 1:30 PM, Antoine Girard <
>> antoine.girard at ymail.com>
>> > wrote:
>> >>
>> >> Also, to come back on the JVM warmup, this will give you enough
>> answers:
>> >>
>> >> https://stackoverflow.com/questions/36198278/why-does-the-
>> jvm-require-warmup
>> >>
>> >> For your, it means that you have to run your tests for a few minutes
>> >> before starting your actual measurements.
>> >>
>> >> I am also interested about how Netty / Jetty perform under the same
>> >> conditions, please post!
>> >>
>> >> Cheers,
>> >> Antoine
>> >>
>> >> On Fri, Jun 23, 2017 at 1:24 AM, Stuart Douglas <sdouglas at redhat.com>
>> >> wrote:
>> >>>
>> >>> Are you actually testing with the 'System.out.println(" Received
>> >>> String ==> "+message);'. System.out is incredibly slow.
>> >>>
>> >>> Stuart
>> >>>
>> >>> On Fri, Jun 23, 2017 at 7:01 AM, SenthilKumar K <
>> senthilec566 at gmail.com>
>> >>> wrote:
>> >>> > Sorry , I'm not an expert in JVM .. How do we do Warm Up JVM ?
>> >>> >
>> >>> > Here is the JVM args to Server:
>> >>> >
>> >>> > nohup java -Xmx4g -Xms4g -XX:MetaspaceSize=96m -XX:+UseG1GC
>> >>> > -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35
>> >>> > -XX:G1HeapRegionSize=16M -XX:MinMetaspaceFreeRatio=50
>> >>> > -XX:MaxMetaspaceFreeRatio=80 -cp undertow-0.0.1.jar
>> HelloWorldServer
>> >>> >
>> >>> >
>> >>> > --Senthil
>> >>> >
>> >>> >
>> >>> > On Fri, Jun 23, 2017 at 2:23 AM, Antoine Girard
>> >>> > <antoine.girard at ymail.com>
>> >>> > wrote:
>> >>> >>
>> >>> >> Do you warm up your jvm prior to the testing?
>> >>> >>
>> >>> >> Cheers,
>> >>> >> Antoine
>> >>> >>
>> >>> >> On Thu, Jun 22, 2017 at 10:42 PM, SenthilKumar K
>> >>> >> <senthilec566 at gmail.com>
>> >>> >> wrote:
>> >>> >>>
>> >>> >>> Thanks Bill n Antoine ..
>> >>> >>>
>> >>> >>>
>> >>> >>> Here is the updated one : ( tried without Kafka API ) .
>> >>> >>>
>> >>> >>> public class HelloWorldServer {
>> >>> >>>
>> >>> >>> public static void main(final String[] args) {
>> >>> >>> Undertow server = Undertow.builder().addHttpListener(8009,
>> >>> >>> "localhost").setHandler(new HttpHandler() {
>> >>> >>> @Override
>> >>> >>> public void handleRequest(final HttpServerExchange exchange)
>> throws
>> >>> >>> Exception {
>> >>> >>> if (exchange.getRequestMethod().equals(Methods.POST)) {
>> >>> >>> exchange.getRequestReceiver().receiveFullString(new
>> >>> >>> Receiver.FullStringCallback() {
>> >>> >>>                    @Override
>> >>> >>>                    public void handle(HttpServerExchange exchange,
>> >>> >>> String
>> >>> >>> message) {
>> >>> >>>                     System.out.println(" Received String ==>
>> >>> >>> "+message);
>> >>> >>>                        exchange.getResponseSender().s
>> end(message);
>> >>> >>>                    }
>> >>> >>>                });
>> >>> >>> } else {
>> >>> >>> exchange.getResponseHeaders().put(Headers.CONTENT_TYPE,
>> >>> >>> "text/plain");
>> >>> >>> exchange.getResponseSender().send("FAILURE");
>> >>> >>> }
>> >>> >>> }
>> >>> >>> }).build();
>> >>> >>> server.start();
>> >>> >>> }
>> >>> >>> }
>> >>> >>>
>> >>> >>>
>> >>> >>> Oops seems to no improvement :
>> >>> >>>
>> >>> >>> Running 1m test @ http://localhost:8009/
>> >>> >>>   100 threads and 1000 connections
>> >>> >>>   Thread Stats   Avg      Stdev     Max   +/- Stdev
>> >>> >>>     Latency    25.79ms   22.18ms 289.48ms   67.66%
>> >>> >>>     Req/Sec   437.76     61.71     2.30k    80.26%
>> >>> >>>   Latency Distribution
>> >>> >>>      50%   22.60ms
>> >>> >>>      75%   37.83ms
>> >>> >>>      90%   55.32ms
>> >>> >>>      99%   90.47ms
>> >>> >>>   2625607 requests in 1.00m, 2.76GB read
>> >>> >>> Requests/sec:  43688.42
>> >>> >>> Transfer/sec:     47.08MB
>> >>> >>>
>> >>> >>>
>> >>> >>> :-( :-( ..
>> >>> >>>
>> >>> >>>
>> >>> >>> --Senthil
>> >>> >>>
>> >>> >>>
>> >>> >>> On Fri, Jun 23, 2017 at 1:47 AM, Antoine Girard
>> >>> >>> <antoine.girard at ymail.com> wrote:
>> >>> >>>>
>> >>> >>>> You can use the Receiver API, specifically for that purpose.
>> >>> >>>> On the exchange, call: getRequestReceiver();
>> >>> >>>>
>> >>> >>>> You will get a receiver object:
>> >>> >>>>
>> >>> >>>>
>> >>> >>>> https://github.com/undertow-io/undertow/blob/master/core/src
>> /main/java/io/undertow/io/Receiver.java
>> >>> >>>>
>> >>> >>>> On the receiver you can call: receiveFullString, you have to
>> pass it
>> >>> >>>> a
>> >>> >>>> callback that will be called when the whole body has been read.
>> >>> >>>>
>> >>> >>>> Please share your results when you test this further!
>> >>> >>>>
>> >>> >>>> Cheers,
>> >>> >>>> Antoine
>> >>> >>>>
>> >>> >>>>
>> >>> >>>> On Thu, Jun 22, 2017 at 8:27 PM, SenthilKumar K
>> >>> >>>> <senthilec566 at gmail.com>
>> >>> >>>> wrote:
>> >>> >>>>>
>> >>> >>>>> Seems to Reading Request body is wrong , So what is the
>> efficient
>> >>> >>>>> way
>> >>> >>>>> of reading request body in undertow ?
>> >>> >>>>>
>> >>> >>>>> --Senthil
>> >>> >>>>>
>> >>> >>>>> On Thu, Jun 22, 2017 at 11:30 PM, SenthilKumar K
>> >>> >>>>> <senthilec566 at gmail.com> wrote:
>> >>> >>>>>>
>> >>> >>>>>> Hello Undertow Dev Team ,
>> >>> >>>>>>
>> >>> >>>>>>       I have been working on the use case where i should create
>> >>> >>>>>> simple
>> >>> >>>>>> http server to serve 1.5 Million Requests per Second per
>> Instance
>> >>> >>>>>> ..
>> >>> >>>>>>
>> >>> >>>>>>
>> >>> >>>>>> Here is the benchmark result of Undertow :
>> >>> >>>>>>
>> >>> >>>>>> Running 1m test @ http://127.0.0.1:8009/
>> >>> >>>>>>   20 threads and 40 connections
>> >>> >>>>>>   Thread Stats   Avg      Stdev     Max   +/- Stdev
>> >>> >>>>>>     Latency     2.51ms   10.75ms 282.22ms   99.28%
>> >>> >>>>>>     Req/Sec     1.12k   316.65     1.96k    54.50%
>> >>> >>>>>>   Latency Distribution
>> >>> >>>>>>      50%    1.43ms
>> >>> >>>>>>      75%    2.38ms
>> >>> >>>>>>      90%    2.90ms
>> >>> >>>>>>      99%   10.45ms
>> >>> >>>>>>   1328133 requests in 1.00m, 167.19MB read
>> >>> >>>>>> Requests/sec:  22127.92
>> >>> >>>>>> Transfer/sec:      2.79MB
>> >>> >>>>>>
>> >>> >>>>>> This is less compared to other frameworks like Jetty and Netty
>> ..
>> >>> >>>>>> But
>> >>> >>>>>> originally Undertow is high performant http server ..
>> >>> >>>>>>
>> >>> >>>>>> Hardware details:
>> >>> >>>>>> Xeon CPU E3-1270 v5 machine with 4 cores ( Clock 100 MHz,
>> Capacity
>> >>> >>>>>> 4
>> >>> >>>>>> GHz) , Memory : 32 G , Available memory 31 G.
>> >>> >>>>>>
>> >>> >>>>>> I would need Undertow experts to review the server code below
>> and
>> >>> >>>>>> advice me on tuning to achieve my goal( ~1.5 Million
>> requests/sec
>> >>> >>>>>> ).
>> >>> >>>>>>
>> >>> >>>>>> Server :
>> >>> >>>>>>
>> >>> >>>>>> Undertow server = Undertow.builder()
>> >>> >>>>>>                .addHttpListener(8009, "localhost")
>> >>> >>>>>>                .setHandler(new Handler()).build();
>> >>> >>>>>> server.start();
>> >>> >>>>>>
>> >>> >>>>>>
>> >>> >>>>>> Handler.Java
>> >>> >>>>>>
>> >>> >>>>>>     final Pooled<ByteBuffer> pooledByteBuffer =
>> >>> >>>>>>
>> >>> >>>>>> exchange.getConnection().getBufferPool().allocate();
>> >>> >>>>>> final ByteBuffer byteBuffer = pooledByteBuffer.getResource();
>> >>> >>>>>>    byteBuffer.clear();
>> >>> >>>>>>    exchange.getRequestChannel().read(byteBuffer);
>> >>> >>>>>>    int pos = byteBuffer.position();
>> >>> >>>>>>    byteBuffer.rewind();
>> >>> >>>>>>    byte[] bytes = new byte[pos];
>> >>> >>>>>>    byteBuffer.get(bytes);
>> >>> >>>>>>    String requestBody = new String(bytes,
>> Charset.forName("UTF-8")
>> >>> >>>>>> );
>> >>> >>>>>>    byteBuffer.clear();
>> >>> >>>>>>    pooledByteBuffer.free();
>> >>> >>>>>>    final PostToKafka post2Kafka = new PostToKafka();
>> >>> >>>>>> try {
>> >>> >>>>>> post2Kafka.write2Kafka(requestBody);  { This API can handle
>> ~2
>> >>> >>>>>> Millions events per sec }
>> >>> >>>>>> } catch (Exception e) {
>> >>> >>>>>> e.printStackTrace();
>> >>> >>>>>> }
>> >>> >>>>>>     exchange.getResponseHeaders().put(Headers.CONTENT_TYPE,
>> >>> >>>>>> "text/plain");
>> >>> >>>>>>     exchange.getResponseSender().send("SUCCESS");
>> >>> >>>>>>
>> >>> >>>>>>
>> >>> >>>>>> --Senthil
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>> _______________________________________________
>> >>> >>>>> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170707/136f28b9/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 25115 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20170707/136f28b9/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 31196 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20170707/136f28b9/attachment-0003.png 

From senthilec566 at gmail.com  Sat Jul  8 10:56:57 2017
From: senthilec566 at gmail.com (SenthilKumar K)
Date: Sat, 8 Jul 2017 20:26:57 +0530
Subject: [undertow-dev] Undertow Http Server - Handling 2 Millions
 Requests Per Second Per Instance
In-Reply-To: <CA+xmZH12c=meg-wv982jAF-tX_5etmq66LVa0VOkB3HhM_ZL-g@mail.gmail.com>
References: <CA+xmZH2ChvRWQGK4X-oFmzxdTzq7R2W7GPv0t=2VrkKDW2a6TQ@mail.gmail.com>
	<CA+xmZH1UDdugtkDvxTp9KdL_h2UtP7QRrz5As-KRj6M8W3DM1g@mail.gmail.com>
	<CALc5U3Fy1POagBsY39aMOtbFjJYRYN0SQs8cTu=jovxtxGx6DA@mail.gmail.com>
	<CA+xmZH3nLf_-JhdYGcbSpB4LzhkHSni3n+OTgj=J9WM=t1YQ6w@mail.gmail.com>
	<CALc5U3F_kYOiNsA9P28EyJM_utqm5LmmZiKusNLQQnobM0TLVg@mail.gmail.com>
	<CA+xmZH3fOcO3L6ztGiqty33jeeXeJjmjGKVqBCXzB3NdkpA2Pg@mail.gmail.com>
	<CAD+L2cw-KCPNCy-+fYheUMTMmj-7+GdAi9y568HcTWKoBX5aOg@mail.gmail.com>
	<CALc5U3HdmPTSeePwft-zc2hRELvim8Rpbr05QYaR-6prpGUo4A@mail.gmail.com>
	<CA+xmZH0OTSpTYhvk94Xt2B66-BaAFKWNNp7YbBbj4+ZQ6ZB9GQ@mail.gmail.com>
	<CAD+L2cy-w8xsu5q2y7vTQzFSy_9V9Jm1X=EaALV6QYp3dVS++A@mail.gmail.com>
	<CANd+gFx4WLY54cPirYOc6PiRByY01HAKLVX0XiEEFOBmae5zxg@mail.gmail.com>
	<CA+xmZH12c=meg-wv982jAF-tX_5etmq66LVa0VOkB3HhM_ZL-g@mail.gmail.com>
Message-ID: <CA+xmZH2p09d_8Pn+Nsje2sndCbwuj8e7FN95Bq78p+JYUZfWKg@mail.gmail.com>

Any comments on *Undertow Vs Netty* ? Am i doing wrong benchmark testing
 ?? Should i change benchmark strategy ?

--Senthil

On Fri, Jul 7, 2017 at 3:14 PM, SenthilKumar K <senthilec566 at gmail.com>
wrote:

> Sorry for delay in responding to this thread!
>
> Thanks to everyone who helped me to Optimize Undertow Server.
>
> Here is the comparison after benchmarking my use case against Netty:
>
> *Undertow Vs Netty :*
>
> Test Case 1 :
> Simple Request Response ( No Kafka ):
>
> *Undertow:*
> Running 10m test @ http://198.18.134.13:8009/
>   500 threads and 5000 connections
>   Thread Stats   Avg      Stdev     Max   +/- Stdev
>     Latency     *3.52m *    2.64m    8.96m    54.63%
>     Req/Sec   376.58    103.18     0.99k    80.53%
>   111628942 requests in 10.00m, 13.72GB read
>   Socket errors: connect 0, read 28, write 0, timeout 2
> Requests/sec: *186122.56*
> Transfer/sec:     23.43MB
>
> *Netty:*
> Running 10m test @ http://198.18.134.13:8009/
> 500 threads and 5000 connections
> Thread Stats   Avg      Stdev     Max   +/- Stdev
>     Latency     *3.77m*     2.10m    7.51m    57.73%
>     Req/Sec   518.63     31.78   652.00     70.25%
>   155406992 requests in 10.00m, 13.82GB read
>   Socket errors: connect 0, read 49, write 0, timeout 0
> Requests/sec: *259107*.30
> Transfer/sec:     24.17MB
>
>
> *Test Case 2:*
> Request --> Read --> Send it Kafka :
>
> *Undertow:*
> Running 10m test @ http://198.18.134.13:8009/
> 500 threads and 5000 connections
> Thread Stats   Avg      Stdev     Max   +/- Stdev
>     Latency     *4.37m *    2.46m    8.72m    57.83%
>     Req/Sec   267.32      5.17   287.00     74.52%
>   80044045 requests in 10.00m, 9.84GB read
>   Socket errors: connect 0, read 121, write 0, timeout 0
> Requests/sec: *133459.79*
> Transfer/sec:     16.80MB
>
> *Netty:*
> Running 10m test @ http://198.18.134.13:8009/
> 500 threads and 5000 connections
> Thread Stats   Avg      Stdev     Max   +/- Stdev
>     Latency     *3.78m *    2.10m    7.55m    57.79%
>     Req/Sec   516.92     28.84   642.00     69.60%
>   154770536 requests in 10.00m, 13.69GB read
>   Socket errors: connect 0, read 11, write 0, timeout 101
> Requests/sec: *258049.39*
> Transfer/sec:     23.38MB
>
>
>
> CPU Usage:
> *Undertow:*
> [image: Inline image 1]
>
> *Netty:*
> [image: Inline image 2]
>
>
> --Senthil
>
> On Thu, Jun 29, 2017 at 7:34 AM, Bill O'Neil <bill at dartalley.com> wrote:
>
>> 1. Can you run the benchmark with the kafka line commented out at first
>> and then again with it not commented out?
>> 2. What rates were you getting with Jetty and Netty?
>> 3. Are you running the tests from the same machine or a different one? If
>> its the same machine and its using 20 threads they will be contending with
>> undertows IO threads.
>> 4. You can probably ignore the POST check if thats all your going to
>> accept and its not a public api.
>>
>> import io.undertow.server.HttpHandler;
>> import io.undertow.server.HttpServerExchange;
>> import io.undertow.util.Headers;
>> import io.undertow.util.Methods;
>>
>> public class DLRHandler implements HttpHandler {
>>
>>     final public static String _SUCCESS="SUCCESS";
>>     final public static String _FAILURE="FAILURE";
>>     final PostToKafka post2Kafka = new PostToKafka();
>>
>>     @Override
>>     public void handleRequest( final HttpServerExchange exchange) throws
>> Exception {
>>         if (exchange.getRequestMethod().equals(Methods.POST)) {
>>               exchange.getRequestReceiver().receiveFullString((
>> exchangeReq, data) -> {
>>                   //post2Kafka.write2Kafka(data); // write it to Kafka
>>                   exchangeReq.getResponseHeaders().put(Headers.CONTENT_TYPE,
>> "text/plain");
>>                   exchangeReq.getResponseSender().send(_SUCCESS);
>>               },
>>              (exchangeReq, exception) -> {
>>                  exchangeReq.getResponseHeaders().put(Headers.CONTENT_TYPE,
>> "text/plain");
>>                  exchangeReq.getResponseSender().send(_FAILURE);
>>             });
>>          }else{
>>              throw new Exception("Method GET not supported by Server ");
>>          }
>>     }
>> }
>>
>> On Wed, Jun 28, 2017 at 6:59 PM, Stuart Douglas <sdouglas at redhat.com>
>> wrote:
>>
>>> The multiple dispatches() are unnecessary (well the second one to the
>>> IO thread is definitely unnecessary, the first one is only required if
>>> post2Kafka.write2Kafka(data); is a blocking operation and needs to be
>>> executed in a worker thread).
>>>
>>> Stuart
>>>
>>> On Wed, Jun 28, 2017 at 5:42 PM, SenthilKumar K <senthilec566 at gmail.com>
>>> wrote:
>>> > After modifying the code below i  could see the improvement ( not much
>>> > slightly ) in server - 65k req/sec.
>>> >
>>> > import io.undertow.server.HttpHandler;
>>> > import io.undertow.server.HttpServerExchange;
>>> > import io.undertow.util.Headers;
>>> > import io.undertow.util.Methods;
>>> >
>>> > public class DLRHandler implements HttpHandler {
>>> >
>>> >     final public static String _SUCCESS="SUCCESS";
>>> >     final public static String _FAILURE="FAILURE";
>>> >     final PostToKafka post2Kafka = new PostToKafka();
>>> >
>>> >     @Override
>>> >     public void handleRequest( final HttpServerExchange exchange)
>>> throws
>>> > Exception {
>>> >         if (exchange.getRequestMethod().equals(Methods.POST)) {
>>> >                 exchange.getRequestReceiver().receiveFullString((
>>> > exchangeReq, data) -> {
>>> >                   exchangeReq.dispatch(() -> {
>>> >                       post2Kafka.write2Kafka(data); // write it to
>>> Kafka
>>> >                       exchangeReq.dispatch(exchangeReq.getIoThread(),
>>> () ->
>>> > {
>>> >
>>> > exchangeReq.getResponseHeaders().put(Headers.CONTENT_TYPE,
>>> "text/plain");
>>> >                           exchangeReq.getResponseSender
>>> ().send(_SUCCESS);
>>> >                       });
>>> >                   });
>>> >               },
>>> >              (exchangeReq, exception) -> {
>>> >                  exchangeReq.getResponseHeaders
>>> ().put(Headers.CONTENT_TYPE,
>>> > "text/plain");
>>> >                  exchangeReq.getResponseSender().send(_FAILURE);
>>> >             });
>>> >          }else{
>>> >              throw new Exception("Method GET not supported by Server
>>> ");
>>> >          }
>>> >     }
>>> > }
>>> >
>>> >
>>> > Pls review this and let me know if i'm doing anything wrong here ...
>>> > --Senthil
>>> >
>>> > On Fri, Jun 23, 2017 at 1:30 PM, Antoine Girard <
>>> antoine.girard at ymail.com>
>>> > wrote:
>>> >>
>>> >> Also, to come back on the JVM warmup, this will give you enough
>>> answers:
>>> >>
>>> >> https://stackoverflow.com/questions/36198278/why-does-the-jv
>>> m-require-warmup
>>> >>
>>> >> For your, it means that you have to run your tests for a few minutes
>>> >> before starting your actual measurements.
>>> >>
>>> >> I am also interested about how Netty / Jetty perform under the same
>>> >> conditions, please post!
>>> >>
>>> >> Cheers,
>>> >> Antoine
>>> >>
>>> >> On Fri, Jun 23, 2017 at 1:24 AM, Stuart Douglas <sdouglas at redhat.com>
>>> >> wrote:
>>> >>>
>>> >>> Are you actually testing with the 'System.out.println(" Received
>>> >>> String ==> "+message);'. System.out is incredibly slow.
>>> >>>
>>> >>> Stuart
>>> >>>
>>> >>> On Fri, Jun 23, 2017 at 7:01 AM, SenthilKumar K <
>>> senthilec566 at gmail.com>
>>> >>> wrote:
>>> >>> > Sorry , I'm not an expert in JVM .. How do we do Warm Up JVM ?
>>> >>> >
>>> >>> > Here is the JVM args to Server:
>>> >>> >
>>> >>> > nohup java -Xmx4g -Xms4g -XX:MetaspaceSize=96m -XX:+UseG1GC
>>> >>> > -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35
>>> >>> > -XX:G1HeapRegionSize=16M -XX:MinMetaspaceFreeRatio=50
>>> >>> > -XX:MaxMetaspaceFreeRatio=80 -cp undertow-0.0.1.jar
>>> HelloWorldServer
>>> >>> >
>>> >>> >
>>> >>> > --Senthil
>>> >>> >
>>> >>> >
>>> >>> > On Fri, Jun 23, 2017 at 2:23 AM, Antoine Girard
>>> >>> > <antoine.girard at ymail.com>
>>> >>> > wrote:
>>> >>> >>
>>> >>> >> Do you warm up your jvm prior to the testing?
>>> >>> >>
>>> >>> >> Cheers,
>>> >>> >> Antoine
>>> >>> >>
>>> >>> >> On Thu, Jun 22, 2017 at 10:42 PM, SenthilKumar K
>>> >>> >> <senthilec566 at gmail.com>
>>> >>> >> wrote:
>>> >>> >>>
>>> >>> >>> Thanks Bill n Antoine ..
>>> >>> >>>
>>> >>> >>>
>>> >>> >>> Here is the updated one : ( tried without Kafka API ) .
>>> >>> >>>
>>> >>> >>> public class HelloWorldServer {
>>> >>> >>>
>>> >>> >>> public static void main(final String[] args) {
>>> >>> >>> Undertow server = Undertow.builder().addHttpListener(8009,
>>> >>> >>> "localhost").setHandler(new HttpHandler() {
>>> >>> >>> @Override
>>> >>> >>> public void handleRequest(final HttpServerExchange exchange)
>>> throws
>>> >>> >>> Exception {
>>> >>> >>> if (exchange.getRequestMethod().equals(Methods.POST)) {
>>> >>> >>> exchange.getRequestReceiver().receiveFullString(new
>>> >>> >>> Receiver.FullStringCallback() {
>>> >>> >>>                    @Override
>>> >>> >>>                    public void handle(HttpServerExchange
>>> exchange,
>>> >>> >>> String
>>> >>> >>> message) {
>>> >>> >>>                     System.out.println(" Received String ==>
>>> >>> >>> "+message);
>>> >>> >>>                        exchange.getResponseSender().s
>>> end(message);
>>> >>> >>>                    }
>>> >>> >>>                });
>>> >>> >>> } else {
>>> >>> >>> exchange.getResponseHeaders().put(Headers.CONTENT_TYPE,
>>> >>> >>> "text/plain");
>>> >>> >>> exchange.getResponseSender().send("FAILURE");
>>> >>> >>> }
>>> >>> >>> }
>>> >>> >>> }).build();
>>> >>> >>> server.start();
>>> >>> >>> }
>>> >>> >>> }
>>> >>> >>>
>>> >>> >>>
>>> >>> >>> Oops seems to no improvement :
>>> >>> >>>
>>> >>> >>> Running 1m test @ http://localhost:8009/
>>> >>> >>>   100 threads and 1000 connections
>>> >>> >>>   Thread Stats   Avg      Stdev     Max   +/- Stdev
>>> >>> >>>     Latency    25.79ms   22.18ms 289.48ms   67.66%
>>> >>> >>>     Req/Sec   437.76     61.71     2.30k    80.26%
>>> >>> >>>   Latency Distribution
>>> >>> >>>      50%   22.60ms
>>> >>> >>>      75%   37.83ms
>>> >>> >>>      90%   55.32ms
>>> >>> >>>      99%   90.47ms
>>> >>> >>>   2625607 requests in 1.00m, 2.76GB read
>>> >>> >>> Requests/sec:  43688.42
>>> >>> >>> Transfer/sec:     47.08MB
>>> >>> >>>
>>> >>> >>>
>>> >>> >>> :-( :-( ..
>>> >>> >>>
>>> >>> >>>
>>> >>> >>> --Senthil
>>> >>> >>>
>>> >>> >>>
>>> >>> >>> On Fri, Jun 23, 2017 at 1:47 AM, Antoine Girard
>>> >>> >>> <antoine.girard at ymail.com> wrote:
>>> >>> >>>>
>>> >>> >>>> You can use the Receiver API, specifically for that purpose.
>>> >>> >>>> On the exchange, call: getRequestReceiver();
>>> >>> >>>>
>>> >>> >>>> You will get a receiver object:
>>> >>> >>>>
>>> >>> >>>>
>>> >>> >>>> https://github.com/undertow-io/undertow/blob/master/core/src
>>> /main/java/io/undertow/io/Receiver.java
>>> >>> >>>>
>>> >>> >>>> On the receiver you can call: receiveFullString, you have to
>>> pass it
>>> >>> >>>> a
>>> >>> >>>> callback that will be called when the whole body has been read.
>>> >>> >>>>
>>> >>> >>>> Please share your results when you test this further!
>>> >>> >>>>
>>> >>> >>>> Cheers,
>>> >>> >>>> Antoine
>>> >>> >>>>
>>> >>> >>>>
>>> >>> >>>> On Thu, Jun 22, 2017 at 8:27 PM, SenthilKumar K
>>> >>> >>>> <senthilec566 at gmail.com>
>>> >>> >>>> wrote:
>>> >>> >>>>>
>>> >>> >>>>> Seems to Reading Request body is wrong , So what is the
>>> efficient
>>> >>> >>>>> way
>>> >>> >>>>> of reading request body in undertow ?
>>> >>> >>>>>
>>> >>> >>>>> --Senthil
>>> >>> >>>>>
>>> >>> >>>>> On Thu, Jun 22, 2017 at 11:30 PM, SenthilKumar K
>>> >>> >>>>> <senthilec566 at gmail.com> wrote:
>>> >>> >>>>>>
>>> >>> >>>>>> Hello Undertow Dev Team ,
>>> >>> >>>>>>
>>> >>> >>>>>>       I have been working on the use case where i should
>>> create
>>> >>> >>>>>> simple
>>> >>> >>>>>> http server to serve 1.5 Million Requests per Second per
>>> Instance
>>> >>> >>>>>> ..
>>> >>> >>>>>>
>>> >>> >>>>>>
>>> >>> >>>>>> Here is the benchmark result of Undertow :
>>> >>> >>>>>>
>>> >>> >>>>>> Running 1m test @ http://127.0.0.1:8009/
>>> >>> >>>>>>   20 threads and 40 connections
>>> >>> >>>>>>   Thread Stats   Avg      Stdev     Max   +/- Stdev
>>> >>> >>>>>>     Latency     2.51ms   10.75ms 282.22ms   99.28%
>>> >>> >>>>>>     Req/Sec     1.12k   316.65     1.96k    54.50%
>>> >>> >>>>>>   Latency Distribution
>>> >>> >>>>>>      50%    1.43ms
>>> >>> >>>>>>      75%    2.38ms
>>> >>> >>>>>>      90%    2.90ms
>>> >>> >>>>>>      99%   10.45ms
>>> >>> >>>>>>   1328133 requests in 1.00m, 167.19MB read
>>> >>> >>>>>> Requests/sec:  22127.92
>>> >>> >>>>>> Transfer/sec:      2.79MB
>>> >>> >>>>>>
>>> >>> >>>>>> This is less compared to other frameworks like Jetty and
>>> Netty ..
>>> >>> >>>>>> But
>>> >>> >>>>>> originally Undertow is high performant http server ..
>>> >>> >>>>>>
>>> >>> >>>>>> Hardware details:
>>> >>> >>>>>> Xeon CPU E3-1270 v5 machine with 4 cores ( Clock 100 MHz,
>>> Capacity
>>> >>> >>>>>> 4
>>> >>> >>>>>> GHz) , Memory : 32 G , Available memory 31 G.
>>> >>> >>>>>>
>>> >>> >>>>>> I would need Undertow experts to review the server code below
>>> and
>>> >>> >>>>>> advice me on tuning to achieve my goal( ~1.5 Million
>>> requests/sec
>>> >>> >>>>>> ).
>>> >>> >>>>>>
>>> >>> >>>>>> Server :
>>> >>> >>>>>>
>>> >>> >>>>>> Undertow server = Undertow.builder()
>>> >>> >>>>>>                .addHttpListener(8009, "localhost")
>>> >>> >>>>>>                .setHandler(new Handler()).build();
>>> >>> >>>>>> server.start();
>>> >>> >>>>>>
>>> >>> >>>>>>
>>> >>> >>>>>> Handler.Java
>>> >>> >>>>>>
>>> >>> >>>>>>     final Pooled<ByteBuffer> pooledByteBuffer =
>>> >>> >>>>>>
>>> >>> >>>>>> exchange.getConnection().getBufferPool().allocate();
>>> >>> >>>>>> final ByteBuffer byteBuffer = pooledByteBuffer.getResource();
>>> >>> >>>>>>    byteBuffer.clear();
>>> >>> >>>>>>    exchange.getRequestChannel().read(byteBuffer);
>>> >>> >>>>>>    int pos = byteBuffer.position();
>>> >>> >>>>>>    byteBuffer.rewind();
>>> >>> >>>>>>    byte[] bytes = new byte[pos];
>>> >>> >>>>>>    byteBuffer.get(bytes);
>>> >>> >>>>>>    String requestBody = new String(bytes,
>>> Charset.forName("UTF-8")
>>> >>> >>>>>> );
>>> >>> >>>>>>    byteBuffer.clear();
>>> >>> >>>>>>    pooledByteBuffer.free();
>>> >>> >>>>>>    final PostToKafka post2Kafka = new PostToKafka();
>>> >>> >>>>>> try {
>>> >>> >>>>>> post2Kafka.write2Kafka(requestBody);  { This API can handle
>>> ~2
>>> >>> >>>>>> Millions events per sec }
>>> >>> >>>>>> } catch (Exception e) {
>>> >>> >>>>>> e.printStackTrace();
>>> >>> >>>>>> }
>>> >>> >>>>>>     exchange.getResponseHeaders().put(Headers.CONTENT_TYPE,
>>> >>> >>>>>> "text/plain");
>>> >>> >>>>>>     exchange.getResponseSender().send("SUCCESS");
>>> >>> >>>>>>
>>> >>> >>>>>>
>>> >>> >>>>>> --Senthil
>>> >>> >>>>>
>>> >>> >>>>>
>>> >>> >>>>>
>>> >>> >>>>> _______________________________________________
>>> >>> >>>>> 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
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170708/27f7d0e3/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 31196 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20170708/27f7d0e3/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 25115 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20170708/27f7d0e3/attachment-0003.png 

From kr at asseco.dk  Sat Jul  8 12:07:51 2017
From: kr at asseco.dk (Kim Rasmussen)
Date: Sat, 08 Jul 2017 16:07:51 +0000
Subject: [undertow-dev] Undertow Http Server - Handling 2 Millions
 Requests Per Second Per Instance
In-Reply-To: <CA+xmZH2p09d_8Pn+Nsje2sndCbwuj8e7FN95Bq78p+JYUZfWKg@mail.gmail.com>
References: <CA+xmZH2ChvRWQGK4X-oFmzxdTzq7R2W7GPv0t=2VrkKDW2a6TQ@mail.gmail.com>
	<CA+xmZH1UDdugtkDvxTp9KdL_h2UtP7QRrz5As-KRj6M8W3DM1g@mail.gmail.com>
	<CALc5U3Fy1POagBsY39aMOtbFjJYRYN0SQs8cTu=jovxtxGx6DA@mail.gmail.com>
	<CA+xmZH3nLf_-JhdYGcbSpB4LzhkHSni3n+OTgj=J9WM=t1YQ6w@mail.gmail.com>
	<CALc5U3F_kYOiNsA9P28EyJM_utqm5LmmZiKusNLQQnobM0TLVg@mail.gmail.com>
	<CA+xmZH3fOcO3L6ztGiqty33jeeXeJjmjGKVqBCXzB3NdkpA2Pg@mail.gmail.com>
	<CAD+L2cw-KCPNCy-+fYheUMTMmj-7+GdAi9y568HcTWKoBX5aOg@mail.gmail.com>
	<CALc5U3HdmPTSeePwft-zc2hRELvim8Rpbr05QYaR-6prpGUo4A@mail.gmail.com>
	<CA+xmZH0OTSpTYhvk94Xt2B66-BaAFKWNNp7YbBbj4+ZQ6ZB9GQ@mail.gmail.com>
	<CAD+L2cy-w8xsu5q2y7vTQzFSy_9V9Jm1X=EaALV6QYp3dVS++A@mail.gmail.com>
	<CANd+gFx4WLY54cPirYOc6PiRByY01HAKLVX0XiEEFOBmae5zxg@mail.gmail.com>
	<CA+xmZH12c=meg-wv982jAF-tX_5etmq66LVa0VOkB3HhM_ZL-g@mail.gmail.com>
	<CA+xmZH2p09d_8Pn+Nsje2sndCbwuj8e7FN95Bq78p+JYUZfWKg@mail.gmail.com>
Message-ID: <CAGX6Y=1vJR_gZ_PzutBPo7+LcrXwdJF+fdhzpfOfg0FTe9Ugrg@mail.gmail.com>

Have you tried playing around with the number of io and worker threads?

l?r. 8. jul. 2017 kl. 17.28 skrev SenthilKumar K <senthilec566 at gmail.com>:

> Any comments on *Undertow Vs Netty* ? Am i doing wrong benchmark testing
>  ?? Should i change benchmark strategy ?
>
> --Senthil
>
> On Fri, Jul 7, 2017 at 3:14 PM, SenthilKumar K <senthilec566 at gmail.com>
> wrote:
>
>> Sorry for delay in responding to this thread!
>>
>> Thanks to everyone who helped me to Optimize Undertow Server.
>>
>> Here is the comparison after benchmarking my use case against Netty:
>>
>> *Undertow Vs Netty :*
>>
>> Test Case 1 :
>> Simple Request Response ( No Kafka ):
>>
>> *Undertow:*
>> Running 10m test @ http://198.18.134.13:8009/
>>   500 threads and 5000 connections
>>   Thread Stats   Avg      Stdev     Max   +/- Stdev
>>     Latency     *3.52m *    2.64m    8.96m    54.63%
>>     Req/Sec   376.58    103.18     0.99k    80.53%
>>   111628942 requests in 10.00m, 13.72GB read
>>   Socket errors: connect 0, read 28, write 0, timeout 2
>> Requests/sec: *186122.56*
>> Transfer/sec:     23.43MB
>>
>> *Netty:*
>> Running 10m test @ http://198.18.134.13:8009/
>> 500 threads and 5000 connections
>> Thread Stats   Avg      Stdev     Max   +/- Stdev
>>     Latency     *3.77m*     2.10m    7.51m    57.73%
>>     Req/Sec   518.63     31.78   652.00     70.25%
>>   155406992 requests in 10.00m, 13.82GB read
>>   Socket errors: connect 0, read 49, write 0, timeout 0
>> Requests/sec: *259107*.30
>> Transfer/sec:     24.17MB
>>
>>
>> *Test Case 2:*
>> Request --> Read --> Send it Kafka :
>>
>> *Undertow:*
>> Running 10m test @ http://198.18.134.13:8009/
>> 500 threads and 5000 connections
>> Thread Stats   Avg      Stdev     Max   +/- Stdev
>>     Latency     *4.37m *    2.46m    8.72m    57.83%
>>     Req/Sec   267.32      5.17   287.00     74.52%
>>   80044045 requests in 10.00m, 9.84GB read
>>   Socket errors: connect 0, read 121, write 0, timeout 0
>> Requests/sec: *133459.79*
>> Transfer/sec:     16.80MB
>>
>> *Netty:*
>> Running 10m test @ http://198.18.134.13:8009/
>> 500 threads and 5000 connections
>> Thread Stats   Avg      Stdev     Max   +/- Stdev
>>     Latency     *3.78m *    2.10m    7.55m    57.79%
>>     Req/Sec   516.92     28.84   642.00     69.60%
>>   154770536 requests in 10.00m, 13.69GB read
>>   Socket errors: connect 0, read 11, write 0, timeout 101
>> Requests/sec: *258049.39*
>> Transfer/sec:     23.38MB
>>
>>
>>
>> CPU Usage:
>> *Undertow:*
>> [image: Inline image 1]
>>
>> *Netty:*
>> [image: Inline image 2]
>>
>>
>> --Senthil
>>
>> On Thu, Jun 29, 2017 at 7:34 AM, Bill O'Neil <bill at dartalley.com> wrote:
>>
>>> 1. Can you run the benchmark with the kafka line commented out at first
>>> and then again with it not commented out?
>>> 2. What rates were you getting with Jetty and Netty?
>>> 3. Are you running the tests from the same machine or a different one?
>>> If its the same machine and its using 20 threads they will be contending
>>> with undertows IO threads.
>>> 4. You can probably ignore the POST check if thats all your going to
>>> accept and its not a public api.
>>>
>>> import io.undertow.server.HttpHandler;
>>> import io.undertow.server.HttpServerExchange;
>>> import io.undertow.util.Headers;
>>> import io.undertow.util.Methods;
>>>
>>> public class DLRHandler implements HttpHandler {
>>>
>>>     final public static String _SUCCESS="SUCCESS";
>>>     final public static String _FAILURE="FAILURE";
>>>     final PostToKafka post2Kafka = new PostToKafka();
>>>
>>>     @Override
>>>     public void handleRequest( final HttpServerExchange exchange) throws
>>> Exception {
>>>         if (exchange.getRequestMethod().equals(Methods.POST)) {
>>>               exchange.getRequestReceiver().receiveFullString((
>>> exchangeReq, data) -> {
>>>                   //post2Kafka.write2Kafka(data); // write it to Kafka
>>>
>>> exchangeReq.getResponseHeaders().put(Headers.CONTENT_TYPE, "text/plain");
>>>                   exchangeReq.getResponseSender().send(_SUCCESS);
>>>               },
>>>              (exchangeReq, exception) -> {
>>>
>>>  exchangeReq.getResponseHeaders().put(Headers.CONTENT_TYPE, "text/plain");
>>>                  exchangeReq.getResponseSender().send(_FAILURE);
>>>             });
>>>          }else{
>>>              throw new Exception("Method GET not supported by Server ");
>>>          }
>>>     }
>>> }
>>>
>>> On Wed, Jun 28, 2017 at 6:59 PM, Stuart Douglas <sdouglas at redhat.com>
>>> wrote:
>>>
>>>> The multiple dispatches() are unnecessary (well the second one to the
>>>> IO thread is definitely unnecessary, the first one is only required if
>>>> post2Kafka.write2Kafka(data); is a blocking operation and needs to be
>>>> executed in a worker thread).
>>>>
>>>> Stuart
>>>>
>>>> On Wed, Jun 28, 2017 at 5:42 PM, SenthilKumar K <senthilec566 at gmail.com>
>>>> wrote:
>>>> > After modifying the code below i  could see the improvement ( not much
>>>> > slightly ) in server - 65k req/sec.
>>>> >
>>>> > import io.undertow.server.HttpHandler;
>>>> > import io.undertow.server.HttpServerExchange;
>>>> > import io.undertow.util.Headers;
>>>> > import io.undertow.util.Methods;
>>>> >
>>>> > public class DLRHandler implements HttpHandler {
>>>> >
>>>> >     final public static String _SUCCESS="SUCCESS";
>>>> >     final public static String _FAILURE="FAILURE";
>>>> >     final PostToKafka post2Kafka = new PostToKafka();
>>>> >
>>>> >     @Override
>>>> >     public void handleRequest( final HttpServerExchange exchange)
>>>> throws
>>>> > Exception {
>>>> >         if (exchange.getRequestMethod().equals(Methods.POST)) {
>>>> >                 exchange.getRequestReceiver().receiveFullString((
>>>> > exchangeReq, data) -> {
>>>> >                   exchangeReq.dispatch(() -> {
>>>> >                       post2Kafka.write2Kafka(data); // write it to
>>>> Kafka
>>>> >                       exchangeReq.dispatch(exchangeReq.getIoThread(),
>>>> () ->
>>>> > {
>>>> >
>>>> > exchangeReq.getResponseHeaders().put(Headers.CONTENT_TYPE,
>>>> "text/plain");
>>>> >
>>>>  exchangeReq.getResponseSender().send(_SUCCESS);
>>>> >                       });
>>>> >                   });
>>>> >               },
>>>> >              (exchangeReq, exception) -> {
>>>> >
>>>> exchangeReq.getResponseHeaders().put(Headers.CONTENT_TYPE,
>>>> > "text/plain");
>>>> >                  exchangeReq.getResponseSender().send(_FAILURE);
>>>> >             });
>>>> >          }else{
>>>> >              throw new Exception("Method GET not supported by Server
>>>> ");
>>>> >          }
>>>> >     }
>>>> > }
>>>> >
>>>> >
>>>> > Pls review this and let me know if i'm doing anything wrong here ...
>>>> > --Senthil
>>>> >
>>>> > On Fri, Jun 23, 2017 at 1:30 PM, Antoine Girard <
>>>> antoine.girard at ymail.com>
>>>> > wrote:
>>>> >>
>>>> >> Also, to come back on the JVM warmup, this will give you enough
>>>> answers:
>>>> >>
>>>> >>
>>>> https://stackoverflow.com/questions/36198278/why-does-the-jvm-require-warmup
>>>> >>
>>>> >> For your, it means that you have to run your tests for a few minutes
>>>> >> before starting your actual measurements.
>>>> >>
>>>> >> I am also interested about how Netty / Jetty perform under the same
>>>> >> conditions, please post!
>>>> >>
>>>> >> Cheers,
>>>> >> Antoine
>>>> >>
>>>> >> On Fri, Jun 23, 2017 at 1:24 AM, Stuart Douglas <sdouglas at redhat.com
>>>> >
>>>> >> wrote:
>>>> >>>
>>>> >>> Are you actually testing with the 'System.out.println(" Received
>>>> >>> String ==> "+message);'. System.out is incredibly slow.
>>>> >>>
>>>> >>> Stuart
>>>> >>>
>>>> >>> On Fri, Jun 23, 2017 at 7:01 AM, SenthilKumar K <
>>>> senthilec566 at gmail.com>
>>>> >>> wrote:
>>>> >>> > Sorry , I'm not an expert in JVM .. How do we do Warm Up JVM ?
>>>> >>> >
>>>> >>> > Here is the JVM args to Server:
>>>> >>> >
>>>> >>> > nohup java -Xmx4g -Xms4g -XX:MetaspaceSize=96m -XX:+UseG1GC
>>>> >>> > -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35
>>>> >>> > -XX:G1HeapRegionSize=16M -XX:MinMetaspaceFreeRatio=50
>>>> >>> > -XX:MaxMetaspaceFreeRatio=80 -cp undertow-0.0.1.jar
>>>> HelloWorldServer
>>>> >>> >
>>>> >>> >
>>>> >>> > --Senthil
>>>> >>> >
>>>> >>> >
>>>> >>> > On Fri, Jun 23, 2017 at 2:23 AM, Antoine Girard
>>>> >>> > <antoine.girard at ymail.com>
>>>> >>> > wrote:
>>>> >>> >>
>>>> >>> >> Do you warm up your jvm prior to the testing?
>>>> >>> >>
>>>> >>> >> Cheers,
>>>> >>> >> Antoine
>>>> >>> >>
>>>> >>> >> On Thu, Jun 22, 2017 at 10:42 PM, SenthilKumar K
>>>> >>> >> <senthilec566 at gmail.com>
>>>> >>> >> wrote:
>>>> >>> >>>
>>>> >>> >>> Thanks Bill n Antoine ..
>>>> >>> >>>
>>>> >>> >>>
>>>> >>> >>> Here is the updated one : ( tried without Kafka API ) .
>>>> >>> >>>
>>>> >>> >>> public class HelloWorldServer {
>>>> >>> >>>
>>>> >>> >>> public static void main(final String[] args) {
>>>> >>> >>> Undertow server = Undertow.builder().addHttpListener(8009,
>>>> >>> >>> "localhost").setHandler(new HttpHandler() {
>>>> >>> >>> @Override
>>>> >>> >>> public void handleRequest(final HttpServerExchange exchange)
>>>> throws
>>>> >>> >>> Exception {
>>>> >>> >>> if (exchange.getRequestMethod().equals(Methods.POST)) {
>>>> >>> >>> exchange.getRequestReceiver().receiveFullString(new
>>>> >>> >>> Receiver.FullStringCallback() {
>>>> >>> >>>                    @Override
>>>> >>> >>>                    public void handle(HttpServerExchange
>>>> exchange,
>>>> >>> >>> String
>>>> >>> >>> message) {
>>>> >>> >>>                     System.out.println(" Received String ==>
>>>> >>> >>> "+message);
>>>> >>> >>>
>>>> exchange.getResponseSender().send(message);
>>>> >>> >>>                    }
>>>> >>> >>>                });
>>>> >>> >>> } else {
>>>> >>> >>> exchange.getResponseHeaders().put(Headers.CONTENT_TYPE,
>>>> >>> >>> "text/plain");
>>>> >>> >>> exchange.getResponseSender().send("FAILURE");
>>>> >>> >>> }
>>>> >>> >>> }
>>>> >>> >>> }).build();
>>>> >>> >>> server.start();
>>>> >>> >>> }
>>>> >>> >>> }
>>>> >>> >>>
>>>> >>> >>>
>>>> >>> >>> Oops seems to no improvement :
>>>> >>> >>>
>>>> >>> >>> Running 1m test @ http://localhost:8009/
>>>> >>> >>>   100 threads and 1000 connections
>>>> >>> >>>   Thread Stats   Avg      Stdev     Max   +/- Stdev
>>>> >>> >>>     Latency    25.79ms   22.18ms 289.48ms   67.66%
>>>> >>> >>>     Req/Sec   437.76     61.71     2.30k    80.26%
>>>> >>> >>>   Latency Distribution
>>>> >>> >>>      50%   22.60ms
>>>> >>> >>>      75%   37.83ms
>>>> >>> >>>      90%   55.32ms
>>>> >>> >>>      99%   90.47ms
>>>> >>> >>>   2625607 requests in 1.00m, 2.76GB read
>>>> >>> >>> Requests/sec:  43688.42
>>>> >>> >>> Transfer/sec:     47.08MB
>>>> >>> >>>
>>>> >>> >>>
>>>> >>> >>> :-( :-( ..
>>>> >>> >>>
>>>> >>> >>>
>>>> >>> >>> --Senthil
>>>> >>> >>>
>>>> >>> >>>
>>>> >>> >>> On Fri, Jun 23, 2017 at 1:47 AM, Antoine Girard
>>>> >>> >>> <antoine.girard at ymail.com> wrote:
>>>> >>> >>>>
>>>> >>> >>>> You can use the Receiver API, specifically for that purpose.
>>>> >>> >>>> On the exchange, call: getRequestReceiver();
>>>> >>> >>>>
>>>> >>> >>>> You will get a receiver object:
>>>> >>> >>>>
>>>> >>> >>>>
>>>> >>> >>>>
>>>> https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/io/Receiver.java
>>>> >>> >>>>
>>>> >>> >>>> On the receiver you can call: receiveFullString, you have to
>>>> pass it
>>>> >>> >>>> a
>>>> >>> >>>> callback that will be called when the whole body has been read.
>>>> >>> >>>>
>>>> >>> >>>> Please share your results when you test this further!
>>>> >>> >>>>
>>>> >>> >>>> Cheers,
>>>> >>> >>>> Antoine
>>>> >>> >>>>
>>>> >>> >>>>
>>>> >>> >>>> On Thu, Jun 22, 2017 at 8:27 PM, SenthilKumar K
>>>> >>> >>>> <senthilec566 at gmail.com>
>>>> >>> >>>> wrote:
>>>> >>> >>>>>
>>>> >>> >>>>> Seems to Reading Request body is wrong , So what is the
>>>> efficient
>>>> >>> >>>>> way
>>>> >>> >>>>> of reading request body in undertow ?
>>>> >>> >>>>>
>>>> >>> >>>>> --Senthil
>>>> >>> >>>>>
>>>> >>> >>>>> On Thu, Jun 22, 2017 at 11:30 PM, SenthilKumar K
>>>> >>> >>>>> <senthilec566 at gmail.com> wrote:
>>>> >>> >>>>>>
>>>> >>> >>>>>> Hello Undertow Dev Team ,
>>>> >>> >>>>>>
>>>> >>> >>>>>>       I have been working on the use case where i should
>>>> create
>>>> >>> >>>>>> simple
>>>> >>> >>>>>> http server to serve 1.5 Million Requests per Second per
>>>> Instance
>>>> >>> >>>>>> ..
>>>> >>> >>>>>>
>>>> >>> >>>>>>
>>>> >>> >>>>>> Here is the benchmark result of Undertow :
>>>> >>> >>>>>>
>>>> >>> >>>>>> Running 1m test @ http://127.0.0.1:8009/
>>>> >>> >>>>>>   20 threads and 40 connections
>>>> >>> >>>>>>   Thread Stats   Avg      Stdev     Max   +/- Stdev
>>>> >>> >>>>>>     Latency     2.51ms   10.75ms 282.22ms   99.28%
>>>> >>> >>>>>>     Req/Sec     1.12k   316.65     1.96k    54.50%
>>>> >>> >>>>>>   Latency Distribution
>>>> >>> >>>>>>      50%    1.43ms
>>>> >>> >>>>>>      75%    2.38ms
>>>> >>> >>>>>>      90%    2.90ms
>>>> >>> >>>>>>      99%   10.45ms
>>>> >>> >>>>>>   1328133 requests in 1.00m, 167.19MB read
>>>> >>> >>>>>> Requests/sec:  22127.92
>>>> >>> >>>>>> Transfer/sec:      2.79MB
>>>> >>> >>>>>>
>>>> >>> >>>>>> This is less compared to other frameworks like Jetty and
>>>> Netty ..
>>>> >>> >>>>>> But
>>>> >>> >>>>>> originally Undertow is high performant http server ..
>>>> >>> >>>>>>
>>>> >>> >>>>>> Hardware details:
>>>> >>> >>>>>> Xeon CPU E3-1270 v5 machine with 4 cores ( Clock 100 MHz,
>>>> Capacity
>>>> >>> >>>>>> 4
>>>> >>> >>>>>> GHz) , Memory : 32 G , Available memory 31 G.
>>>> >>> >>>>>>
>>>> >>> >>>>>> I would need Undertow experts to review the server code
>>>> below and
>>>> >>> >>>>>> advice me on tuning to achieve my goal( ~1.5 Million
>>>> requests/sec
>>>> >>> >>>>>> ).
>>>> >>> >>>>>>
>>>> >>> >>>>>> Server :
>>>> >>> >>>>>>
>>>> >>> >>>>>> Undertow server = Undertow.builder()
>>>> >>> >>>>>>                .addHttpListener(8009, "localhost")
>>>> >>> >>>>>>                .setHandler(new Handler()).build();
>>>> >>> >>>>>> server.start();
>>>> >>> >>>>>>
>>>> >>> >>>>>>
>>>> >>> >>>>>> Handler.Java
>>>> >>> >>>>>>
>>>> >>> >>>>>>     final Pooled<ByteBuffer> pooledByteBuffer =
>>>> >>> >>>>>>
>>>> >>> >>>>>> exchange.getConnection().getBufferPool().allocate();
>>>> >>> >>>>>> final ByteBuffer byteBuffer = pooledByteBuffer.getResource();
>>>> >>> >>>>>>    byteBuffer.clear();
>>>> >>> >>>>>>    exchange.getRequestChannel().read(byteBuffer);
>>>> >>> >>>>>>    int pos = byteBuffer.position();
>>>> >>> >>>>>>    byteBuffer.rewind();
>>>> >>> >>>>>>    byte[] bytes = new byte[pos];
>>>> >>> >>>>>>    byteBuffer.get(bytes);
>>>> >>> >>>>>>    String requestBody = new String(bytes,
>>>> Charset.forName("UTF-8")
>>>> >>> >>>>>> );
>>>> >>> >>>>>>    byteBuffer.clear();
>>>> >>> >>>>>>    pooledByteBuffer.free();
>>>> >>> >>>>>>    final PostToKafka post2Kafka = new PostToKafka();
>>>> >>> >>>>>> try {
>>>> >>> >>>>>> post2Kafka.write2Kafka(requestBody);  { This API can handle
>>>> ~2
>>>> >>> >>>>>> Millions events per sec }
>>>> >>> >>>>>> } catch (Exception e) {
>>>> >>> >>>>>> e.printStackTrace();
>>>> >>> >>>>>> }
>>>> >>> >>>>>>     exchange.getResponseHeaders().put(Headers.CONTENT_TYPE,
>>>> >>> >>>>>> "text/plain");
>>>> >>> >>>>>>     exchange.getResponseSender().send("SUCCESS");
>>>> >>> >>>>>>
>>>> >>> >>>>>>
>>>> >>> >>>>>> --Senthil
>>>> >>> >>>>>
>>>> >>> >>>>>
>>>> >>> >>>>>
>>>> >>> >>>>> _______________________________________________
>>>> >>> >>>>> 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
>>>>
>>>
>>>
>>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

-- 
Med venlig hilsen / Best regards

*Kim Rasmussen*
Partner, IT Architect

*Asseco Denmark A/S*
Kronprinsessegade 54
DK-1306 Copenhagen K
Mobile: +45 26 16 40 23
Ph.: +45 33 36 46 60
Fax: +45 33 36 46 61
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170708/5304450b/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 25115 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20170708/5304450b/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 31196 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20170708/5304450b/attachment-0003.png 

From senthilec566 at gmail.com  Sat Jul  8 12:17:49 2017
From: senthilec566 at gmail.com (SenthilKumar K)
Date: Sat, 8 Jul 2017 21:47:49 +0530
Subject: [undertow-dev] Undertow Http Server - Handling 2 Millions
 Requests Per Second Per Instance
In-Reply-To: <CAGX6Y=1vJR_gZ_PzutBPo7+LcrXwdJF+fdhzpfOfg0FTe9Ugrg@mail.gmail.com>
References: <CA+xmZH2ChvRWQGK4X-oFmzxdTzq7R2W7GPv0t=2VrkKDW2a6TQ@mail.gmail.com>
	<CA+xmZH1UDdugtkDvxTp9KdL_h2UtP7QRrz5As-KRj6M8W3DM1g@mail.gmail.com>
	<CALc5U3Fy1POagBsY39aMOtbFjJYRYN0SQs8cTu=jovxtxGx6DA@mail.gmail.com>
	<CA+xmZH3nLf_-JhdYGcbSpB4LzhkHSni3n+OTgj=J9WM=t1YQ6w@mail.gmail.com>
	<CALc5U3F_kYOiNsA9P28EyJM_utqm5LmmZiKusNLQQnobM0TLVg@mail.gmail.com>
	<CA+xmZH3fOcO3L6ztGiqty33jeeXeJjmjGKVqBCXzB3NdkpA2Pg@mail.gmail.com>
	<CAD+L2cw-KCPNCy-+fYheUMTMmj-7+GdAi9y568HcTWKoBX5aOg@mail.gmail.com>
	<CALc5U3HdmPTSeePwft-zc2hRELvim8Rpbr05QYaR-6prpGUo4A@mail.gmail.com>
	<CA+xmZH0OTSpTYhvk94Xt2B66-BaAFKWNNp7YbBbj4+ZQ6ZB9GQ@mail.gmail.com>
	<CAD+L2cy-w8xsu5q2y7vTQzFSy_9V9Jm1X=EaALV6QYp3dVS++A@mail.gmail.com>
	<CANd+gFx4WLY54cPirYOc6PiRByY01HAKLVX0XiEEFOBmae5zxg@mail.gmail.com>
	<CA+xmZH12c=meg-wv982jAF-tX_5etmq66LVa0VOkB3HhM_ZL-g@mail.gmail.com>
	<CA+xmZH2p09d_8Pn+Nsje2sndCbwuj8e7FN95Bq78p+JYUZfWKg@mail.gmail.com>
	<CAGX6Y=1vJR_gZ_PzutBPo7+LcrXwdJF+fdhzpfOfg0FTe9Ugrg@mail.gmail.com>
Message-ID: <CA+xmZH1dvBrEft3ERNe6kpVGgO=R2D0ciqjwKLjQ_GcXhMFrWA@mail.gmail.com>

Yet to try that .. My testcase  did not cover tuning no of threads .. but
even if we try to increase number of threads I believe both framework
performance would improve !! Different thoughts ??

Anyway I like to add another test case by changing threads !!

--Senthil

On Jul 8, 2017 9:38 PM, "Kim Rasmussen" <kr at asseco.dk> wrote:

> Have you tried playing around with the number of io and worker threads?
>
> l?r. 8. jul. 2017 kl. 17.28 skrev SenthilKumar K <senthilec566 at gmail.com>:
>
>> Any comments on *Undertow Vs Netty* ? Am i doing wrong benchmark testing
>>  ?? Should i change benchmark strategy ?
>>
>> --Senthil
>>
>> On Fri, Jul 7, 2017 at 3:14 PM, SenthilKumar K <senthilec566 at gmail.com>
>> wrote:
>>
>>> Sorry for delay in responding to this thread!
>>>
>>> Thanks to everyone who helped me to Optimize Undertow Server.
>>>
>>> Here is the comparison after benchmarking my use case against Netty:
>>>
>>> *Undertow Vs Netty :*
>>>
>>> Test Case 1 :
>>> Simple Request Response ( No Kafka ):
>>>
>>> *Undertow:*
>>> Running 10m test @ http://198.18.134.13:8009/
>>>   500 threads and 5000 connections
>>>   Thread Stats   Avg      Stdev     Max   +/- Stdev
>>>     Latency     *3.52m *    2.64m    8.96m    54.63%
>>>     Req/Sec   376.58    103.18     0.99k    80.53%
>>>   111628942 requests in 10.00m, 13.72GB read
>>>   Socket errors: connect 0, read 28, write 0, timeout 2
>>> Requests/sec: *186122.56*
>>> Transfer/sec:     23.43MB
>>>
>>> *Netty:*
>>> Running 10m test @ http://198.18.134.13:8009/
>>> 500 threads and 5000 connections
>>> Thread Stats   Avg      Stdev     Max   +/- Stdev
>>>     Latency     *3.77m*     2.10m    7.51m    57.73%
>>>     Req/Sec   518.63     31.78   652.00     70.25%
>>>   155406992 requests in 10.00m, 13.82GB read
>>>   Socket errors: connect 0, read 49, write 0, timeout 0
>>> Requests/sec: *259107*.30
>>> Transfer/sec:     24.17MB
>>>
>>>
>>> *Test Case 2:*
>>> Request --> Read --> Send it Kafka :
>>>
>>> *Undertow:*
>>> Running 10m test @ http://198.18.134.13:8009/
>>> 500 threads and 5000 connections
>>> Thread Stats   Avg      Stdev     Max   +/- Stdev
>>>     Latency     *4.37m *    2.46m    8.72m    57.83%
>>>     Req/Sec   267.32      5.17   287.00     74.52%
>>>   80044045 requests in 10.00m, 9.84GB read
>>>   Socket errors: connect 0, read 121, write 0, timeout 0
>>> Requests/sec: *133459.79*
>>> Transfer/sec:     16.80MB
>>>
>>> *Netty:*
>>> Running 10m test @ http://198.18.134.13:8009/
>>> 500 threads and 5000 connections
>>> Thread Stats   Avg      Stdev     Max   +/- Stdev
>>>     Latency     *3.78m *    2.10m    7.55m    57.79%
>>>     Req/Sec   516.92     28.84   642.00     69.60%
>>>   154770536 requests in 10.00m, 13.69GB read
>>>   Socket errors: connect 0, read 11, write 0, timeout 101
>>> Requests/sec: *258049.39*
>>> Transfer/sec:     23.38MB
>>>
>>>
>>>
>>> CPU Usage:
>>> *Undertow:*
>>> [image: Inline image 1]
>>>
>>> *Netty:*
>>> [image: Inline image 2]
>>>
>>>
>>> --Senthil
>>>
>>> On Thu, Jun 29, 2017 at 7:34 AM, Bill O'Neil <bill at dartalley.com> wrote:
>>>
>>>> 1. Can you run the benchmark with the kafka line commented out at first
>>>> and then again with it not commented out?
>>>> 2. What rates were you getting with Jetty and Netty?
>>>> 3. Are you running the tests from the same machine or a different one?
>>>> If its the same machine and its using 20 threads they will be contending
>>>> with undertows IO threads.
>>>> 4. You can probably ignore the POST check if thats all your going to
>>>> accept and its not a public api.
>>>>
>>>> import io.undertow.server.HttpHandler;
>>>> import io.undertow.server.HttpServerExchange;
>>>> import io.undertow.util.Headers;
>>>> import io.undertow.util.Methods;
>>>>
>>>> public class DLRHandler implements HttpHandler {
>>>>
>>>>     final public static String _SUCCESS="SUCCESS";
>>>>     final public static String _FAILURE="FAILURE";
>>>>     final PostToKafka post2Kafka = new PostToKafka();
>>>>
>>>>     @Override
>>>>     public void handleRequest( final HttpServerExchange exchange)
>>>> throws Exception {
>>>>         if (exchange.getRequestMethod().equals(Methods.POST)) {
>>>>               exchange.getRequestReceiver().receiveFullString((
>>>> exchangeReq, data) -> {
>>>>                   //post2Kafka.write2Kafka(data); // write it to Kafka
>>>>                   exchangeReq.getResponseHeaders().put(Headers.CONTENT_TYPE,
>>>> "text/plain");
>>>>                   exchangeReq.getResponseSender().send(_SUCCESS);
>>>>               },
>>>>              (exchangeReq, exception) -> {
>>>>                  exchangeReq.getResponseHeaders().put(Headers.CONTENT_TYPE,
>>>> "text/plain");
>>>>                  exchangeReq.getResponseSender().send(_FAILURE);
>>>>             });
>>>>          }else{
>>>>              throw new Exception("Method GET not supported by Server ");
>>>>          }
>>>>     }
>>>> }
>>>>
>>>> On Wed, Jun 28, 2017 at 6:59 PM, Stuart Douglas <sdouglas at redhat.com>
>>>> wrote:
>>>>
>>>>> The multiple dispatches() are unnecessary (well the second one to the
>>>>> IO thread is definitely unnecessary, the first one is only required if
>>>>> post2Kafka.write2Kafka(data); is a blocking operation and needs to be
>>>>> executed in a worker thread).
>>>>>
>>>>> Stuart
>>>>>
>>>>> On Wed, Jun 28, 2017 at 5:42 PM, SenthilKumar K <
>>>>> senthilec566 at gmail.com> wrote:
>>>>> > After modifying the code below i  could see the improvement ( not
>>>>> much
>>>>> > slightly ) in server - 65k req/sec.
>>>>> >
>>>>> > import io.undertow.server.HttpHandler;
>>>>> > import io.undertow.server.HttpServerExchange;
>>>>> > import io.undertow.util.Headers;
>>>>> > import io.undertow.util.Methods;
>>>>> >
>>>>> > public class DLRHandler implements HttpHandler {
>>>>> >
>>>>> >     final public static String _SUCCESS="SUCCESS";
>>>>> >     final public static String _FAILURE="FAILURE";
>>>>> >     final PostToKafka post2Kafka = new PostToKafka();
>>>>> >
>>>>> >     @Override
>>>>> >     public void handleRequest( final HttpServerExchange exchange)
>>>>> throws
>>>>> > Exception {
>>>>> >         if (exchange.getRequestMethod().equals(Methods.POST)) {
>>>>> >                 exchange.getRequestReceiver().receiveFullString((
>>>>> > exchangeReq, data) -> {
>>>>> >                   exchangeReq.dispatch(() -> {
>>>>> >                       post2Kafka.write2Kafka(data); // write it to
>>>>> Kafka
>>>>> >                       exchangeReq.dispatch(exchangeReq.getIoThread(),
>>>>> () ->
>>>>> > {
>>>>> >
>>>>> > exchangeReq.getResponseHeaders().put(Headers.CONTENT_TYPE,
>>>>> "text/plain");
>>>>> >                           exchangeReq.getResponseSender().send(_
>>>>> SUCCESS);
>>>>> >                       });
>>>>> >                   });
>>>>> >               },
>>>>> >              (exchangeReq, exception) -> {
>>>>> >                  exchangeReq.getResponseHeaders().put(
>>>>> Headers.CONTENT_TYPE,
>>>>> > "text/plain");
>>>>> >                  exchangeReq.getResponseSender().send(_FAILURE);
>>>>> >             });
>>>>> >          }else{
>>>>> >              throw new Exception("Method GET not supported by Server
>>>>> ");
>>>>> >          }
>>>>> >     }
>>>>> > }
>>>>> >
>>>>> >
>>>>> > Pls review this and let me know if i'm doing anything wrong here ...
>>>>> > --Senthil
>>>>> >
>>>>> > On Fri, Jun 23, 2017 at 1:30 PM, Antoine Girard <
>>>>> antoine.girard at ymail.com>
>>>>> > wrote:
>>>>> >>
>>>>> >> Also, to come back on the JVM warmup, this will give you enough
>>>>> answers:
>>>>> >>
>>>>> >> https://stackoverflow.com/questions/36198278/why-does-
>>>>> the-jvm-require-warmup
>>>>> >>
>>>>> >> For your, it means that you have to run your tests for a few minutes
>>>>> >> before starting your actual measurements.
>>>>> >>
>>>>> >> I am also interested about how Netty / Jetty perform under the same
>>>>> >> conditions, please post!
>>>>> >>
>>>>> >> Cheers,
>>>>> >> Antoine
>>>>> >>
>>>>> >> On Fri, Jun 23, 2017 at 1:24 AM, Stuart Douglas <
>>>>> sdouglas at redhat.com>
>>>>> >> wrote:
>>>>> >>>
>>>>> >>> Are you actually testing with the 'System.out.println(" Received
>>>>> >>> String ==> "+message);'. System.out is incredibly slow.
>>>>> >>>
>>>>> >>> Stuart
>>>>> >>>
>>>>> >>> On Fri, Jun 23, 2017 at 7:01 AM, SenthilKumar K <
>>>>> senthilec566 at gmail.com>
>>>>> >>> wrote:
>>>>> >>> > Sorry , I'm not an expert in JVM .. How do we do Warm Up JVM ?
>>>>> >>> >
>>>>> >>> > Here is the JVM args to Server:
>>>>> >>> >
>>>>> >>> > nohup java -Xmx4g -Xms4g -XX:MetaspaceSize=96m -XX:+UseG1GC
>>>>> >>> > -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35
>>>>> >>> > -XX:G1HeapRegionSize=16M -XX:MinMetaspaceFreeRatio=50
>>>>> >>> > -XX:MaxMetaspaceFreeRatio=80 -cp undertow-0.0.1.jar
>>>>> HelloWorldServer
>>>>> >>> >
>>>>> >>> >
>>>>> >>> > --Senthil
>>>>> >>> >
>>>>> >>> >
>>>>> >>> > On Fri, Jun 23, 2017 at 2:23 AM, Antoine Girard
>>>>> >>> > <antoine.girard at ymail.com>
>>>>> >>> > wrote:
>>>>> >>> >>
>>>>> >>> >> Do you warm up your jvm prior to the testing?
>>>>> >>> >>
>>>>> >>> >> Cheers,
>>>>> >>> >> Antoine
>>>>> >>> >>
>>>>> >>> >> On Thu, Jun 22, 2017 at 10:42 PM, SenthilKumar K
>>>>> >>> >> <senthilec566 at gmail.com>
>>>>> >>> >> wrote:
>>>>> >>> >>>
>>>>> >>> >>> Thanks Bill n Antoine ..
>>>>> >>> >>>
>>>>> >>> >>>
>>>>> >>> >>> Here is the updated one : ( tried without Kafka API ) .
>>>>> >>> >>>
>>>>> >>> >>> public class HelloWorldServer {
>>>>> >>> >>>
>>>>> >>> >>> public static void main(final String[] args) {
>>>>> >>> >>> Undertow server = Undertow.builder().addHttpListener(8009,
>>>>> >>> >>> "localhost").setHandler(new HttpHandler() {
>>>>> >>> >>> @Override
>>>>> >>> >>> public void handleRequest(final HttpServerExchange exchange)
>>>>> throws
>>>>> >>> >>> Exception {
>>>>> >>> >>> if (exchange.getRequestMethod().equals(Methods.POST)) {
>>>>> >>> >>> exchange.getRequestReceiver().receiveFullString(new
>>>>> >>> >>> Receiver.FullStringCallback() {
>>>>> >>> >>>                    @Override
>>>>> >>> >>>                    public void handle(HttpServerExchange
>>>>> exchange,
>>>>> >>> >>> String
>>>>> >>> >>> message) {
>>>>> >>> >>>                     System.out.println(" Received String ==>
>>>>> >>> >>> "+message);
>>>>> >>> >>>                        exchange.getResponseSender().
>>>>> send(message);
>>>>> >>> >>>                    }
>>>>> >>> >>>                });
>>>>> >>> >>> } else {
>>>>> >>> >>> exchange.getResponseHeaders().put(Headers.CONTENT_TYPE,
>>>>> >>> >>> "text/plain");
>>>>> >>> >>> exchange.getResponseSender().send("FAILURE");
>>>>> >>> >>> }
>>>>> >>> >>> }
>>>>> >>> >>> }).build();
>>>>> >>> >>> server.start();
>>>>> >>> >>> }
>>>>> >>> >>> }
>>>>> >>> >>>
>>>>> >>> >>>
>>>>> >>> >>> Oops seems to no improvement :
>>>>> >>> >>>
>>>>> >>> >>> Running 1m test @ http://localhost:8009/
>>>>> >>> >>>   100 threads and 1000 connections
>>>>> >>> >>>   Thread Stats   Avg      Stdev     Max   +/- Stdev
>>>>> >>> >>>     Latency    25.79ms   22.18ms 289.48ms   67.66%
>>>>> >>> >>>     Req/Sec   437.76     61.71     2.30k    80.26%
>>>>> >>> >>>   Latency Distribution
>>>>> >>> >>>      50%   22.60ms
>>>>> >>> >>>      75%   37.83ms
>>>>> >>> >>>      90%   55.32ms
>>>>> >>> >>>      99%   90.47ms
>>>>> >>> >>>   2625607 requests in 1.00m, 2.76GB read
>>>>> >>> >>> Requests/sec:  43688.42
>>>>> >>> >>> Transfer/sec:     47.08MB
>>>>> >>> >>>
>>>>> >>> >>>
>>>>> >>> >>> :-( :-( ..
>>>>> >>> >>>
>>>>> >>> >>>
>>>>> >>> >>> --Senthil
>>>>> >>> >>>
>>>>> >>> >>>
>>>>> >>> >>> On Fri, Jun 23, 2017 at 1:47 AM, Antoine Girard
>>>>> >>> >>> <antoine.girard at ymail.com> wrote:
>>>>> >>> >>>>
>>>>> >>> >>>> You can use the Receiver API, specifically for that purpose.
>>>>> >>> >>>> On the exchange, call: getRequestReceiver();
>>>>> >>> >>>>
>>>>> >>> >>>> You will get a receiver object:
>>>>> >>> >>>>
>>>>> >>> >>>>
>>>>> >>> >>>> https://github.com/undertow-io/undertow/blob/master/core/
>>>>> src/main/java/io/undertow/io/Receiver.java
>>>>> >>> >>>>
>>>>> >>> >>>> On the receiver you can call: receiveFullString, you have to
>>>>> pass it
>>>>> >>> >>>> a
>>>>> >>> >>>> callback that will be called when the whole body has been
>>>>> read.
>>>>> >>> >>>>
>>>>> >>> >>>> Please share your results when you test this further!
>>>>> >>> >>>>
>>>>> >>> >>>> Cheers,
>>>>> >>> >>>> Antoine
>>>>> >>> >>>>
>>>>> >>> >>>>
>>>>> >>> >>>> On Thu, Jun 22, 2017 at 8:27 PM, SenthilKumar K
>>>>> >>> >>>> <senthilec566 at gmail.com>
>>>>> >>> >>>> wrote:
>>>>> >>> >>>>>
>>>>> >>> >>>>> Seems to Reading Request body is wrong , So what is the
>>>>> efficient
>>>>> >>> >>>>> way
>>>>> >>> >>>>> of reading request body in undertow ?
>>>>> >>> >>>>>
>>>>> >>> >>>>> --Senthil
>>>>> >>> >>>>>
>>>>> >>> >>>>> On Thu, Jun 22, 2017 at 11:30 PM, SenthilKumar K
>>>>> >>> >>>>> <senthilec566 at gmail.com> wrote:
>>>>> >>> >>>>>>
>>>>> >>> >>>>>> Hello Undertow Dev Team ,
>>>>> >>> >>>>>>
>>>>> >>> >>>>>>       I have been working on the use case where i should
>>>>> create
>>>>> >>> >>>>>> simple
>>>>> >>> >>>>>> http server to serve 1.5 Million Requests per Second per
>>>>> Instance
>>>>> >>> >>>>>> ..
>>>>> >>> >>>>>>
>>>>> >>> >>>>>>
>>>>> >>> >>>>>> Here is the benchmark result of Undertow :
>>>>> >>> >>>>>>
>>>>> >>> >>>>>> Running 1m test @ http://127.0.0.1:8009/
>>>>> >>> >>>>>>   20 threads and 40 connections
>>>>> >>> >>>>>>   Thread Stats   Avg      Stdev     Max   +/- Stdev
>>>>> >>> >>>>>>     Latency     2.51ms   10.75ms 282.22ms   99.28%
>>>>> >>> >>>>>>     Req/Sec     1.12k   316.65     1.96k    54.50%
>>>>> >>> >>>>>>   Latency Distribution
>>>>> >>> >>>>>>      50%    1.43ms
>>>>> >>> >>>>>>      75%    2.38ms
>>>>> >>> >>>>>>      90%    2.90ms
>>>>> >>> >>>>>>      99%   10.45ms
>>>>> >>> >>>>>>   1328133 requests in 1.00m, 167.19MB read
>>>>> >>> >>>>>> Requests/sec:  22127.92
>>>>> >>> >>>>>> Transfer/sec:      2.79MB
>>>>> >>> >>>>>>
>>>>> >>> >>>>>> This is less compared to other frameworks like Jetty and
>>>>> Netty ..
>>>>> >>> >>>>>> But
>>>>> >>> >>>>>> originally Undertow is high performant http server ..
>>>>> >>> >>>>>>
>>>>> >>> >>>>>> Hardware details:
>>>>> >>> >>>>>> Xeon CPU E3-1270 v5 machine with 4 cores ( Clock 100 MHz,
>>>>> Capacity
>>>>> >>> >>>>>> 4
>>>>> >>> >>>>>> GHz) , Memory : 32 G , Available memory 31 G.
>>>>> >>> >>>>>>
>>>>> >>> >>>>>> I would need Undertow experts to review the server code
>>>>> below and
>>>>> >>> >>>>>> advice me on tuning to achieve my goal( ~1.5 Million
>>>>> requests/sec
>>>>> >>> >>>>>> ).
>>>>> >>> >>>>>>
>>>>> >>> >>>>>> Server :
>>>>> >>> >>>>>>
>>>>> >>> >>>>>> Undertow server = Undertow.builder()
>>>>> >>> >>>>>>                .addHttpListener(8009, "localhost")
>>>>> >>> >>>>>>                .setHandler(new Handler()).build();
>>>>> >>> >>>>>> server.start();
>>>>> >>> >>>>>>
>>>>> >>> >>>>>>
>>>>> >>> >>>>>> Handler.Java
>>>>> >>> >>>>>>
>>>>> >>> >>>>>>     final Pooled<ByteBuffer> pooledByteBuffer =
>>>>> >>> >>>>>>
>>>>> >>> >>>>>> exchange.getConnection().getBufferPool().allocate();
>>>>> >>> >>>>>> final ByteBuffer byteBuffer = pooledByteBuffer.getResource()
>>>>> ;
>>>>> >>> >>>>>>    byteBuffer.clear();
>>>>> >>> >>>>>>    exchange.getRequestChannel().read(byteBuffer);
>>>>> >>> >>>>>>    int pos = byteBuffer.position();
>>>>> >>> >>>>>>    byteBuffer.rewind();
>>>>> >>> >>>>>>    byte[] bytes = new byte[pos];
>>>>> >>> >>>>>>    byteBuffer.get(bytes);
>>>>> >>> >>>>>>    String requestBody = new String(bytes,
>>>>> Charset.forName("UTF-8")
>>>>> >>> >>>>>> );
>>>>> >>> >>>>>>    byteBuffer.clear();
>>>>> >>> >>>>>>    pooledByteBuffer.free();
>>>>> >>> >>>>>>    final PostToKafka post2Kafka = new PostToKafka();
>>>>> >>> >>>>>> try {
>>>>> >>> >>>>>> post2Kafka.write2Kafka(requestBody);  { This API can
>>>>> handle  ~2
>>>>> >>> >>>>>> Millions events per sec }
>>>>> >>> >>>>>> } catch (Exception e) {
>>>>> >>> >>>>>> e.printStackTrace();
>>>>> >>> >>>>>> }
>>>>> >>> >>>>>>     exchange.getResponseHeaders().put(Headers.CONTENT_TYPE,
>>>>> >>> >>>>>> "text/plain");
>>>>> >>> >>>>>>     exchange.getResponseSender().send("SUCCESS");
>>>>> >>> >>>>>>
>>>>> >>> >>>>>>
>>>>> >>> >>>>>> --Senthil
>>>>> >>> >>>>>
>>>>> >>> >>>>>
>>>>> >>> >>>>>
>>>>> >>> >>>>> _______________________________________________
>>>>> >>> >>>>> 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
>>>>>
>>>>
>>>>
>>>
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
> --
> Med venlig hilsen / Best regards
>
> *Kim Rasmussen*
> Partner, IT Architect
>
> *Asseco Denmark A/S*
> Kronprinsessegade 54
> DK-1306 Copenhagen K
> Mobile: +45 26 16 40 23
> Ph.: +45 33 36 46 60
> Fax: +45 33 36 46 61
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170708/7625bb90/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 25115 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20170708/7625bb90/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 31196 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20170708/7625bb90/attachment-0003.png 

From sdouglas at redhat.com  Sun Jul  9 17:39:42 2017
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 10 Jul 2017 09:39:42 +1200
Subject: [undertow-dev] Undertow Http Server - Handling 2 Millions
 Requests Per Second Per Instance
In-Reply-To: <CA+xmZH1dvBrEft3ERNe6kpVGgO=R2D0ciqjwKLjQ_GcXhMFrWA@mail.gmail.com>
References: <CA+xmZH2ChvRWQGK4X-oFmzxdTzq7R2W7GPv0t=2VrkKDW2a6TQ@mail.gmail.com>
	<CA+xmZH1UDdugtkDvxTp9KdL_h2UtP7QRrz5As-KRj6M8W3DM1g@mail.gmail.com>
	<CALc5U3Fy1POagBsY39aMOtbFjJYRYN0SQs8cTu=jovxtxGx6DA@mail.gmail.com>
	<CA+xmZH3nLf_-JhdYGcbSpB4LzhkHSni3n+OTgj=J9WM=t1YQ6w@mail.gmail.com>
	<CALc5U3F_kYOiNsA9P28EyJM_utqm5LmmZiKusNLQQnobM0TLVg@mail.gmail.com>
	<CA+xmZH3fOcO3L6ztGiqty33jeeXeJjmjGKVqBCXzB3NdkpA2Pg@mail.gmail.com>
	<CAD+L2cw-KCPNCy-+fYheUMTMmj-7+GdAi9y568HcTWKoBX5aOg@mail.gmail.com>
	<CALc5U3HdmPTSeePwft-zc2hRELvim8Rpbr05QYaR-6prpGUo4A@mail.gmail.com>
	<CA+xmZH0OTSpTYhvk94Xt2B66-BaAFKWNNp7YbBbj4+ZQ6ZB9GQ@mail.gmail.com>
	<CAD+L2cy-w8xsu5q2y7vTQzFSy_9V9Jm1X=EaALV6QYp3dVS++A@mail.gmail.com>
	<CANd+gFx4WLY54cPirYOc6PiRByY01HAKLVX0XiEEFOBmae5zxg@mail.gmail.com>
	<CA+xmZH12c=meg-wv982jAF-tX_5etmq66LVa0VOkB3HhM_ZL-g@mail.gmail.com>
	<CA+xmZH2p09d_8Pn+Nsje2sndCbwuj8e7FN95Bq78p+JYUZfWKg@mail.gmail.com>
	<CAGX6Y=1vJR_gZ_PzutBPo7+LcrXwdJF+fdhzpfOfg0FTe9Ugrg@mail.gmail.com>
	<CA+xmZH1dvBrEft3ERNe6kpVGgO=R2D0ciqjwKLjQ_GcXhMFrWA@mail.gmail.com>
Message-ID: <CAD+L2cwuxju5Q0e0NG+Soaxz6evfALsN-KLvw-1haTucPL4XtQ@mail.gmail.com>

Are they both using the same number of threads? Also what are you doing in
the handler? Are you calling dispatch? Dispatch is relativity slow in these
micro benchmarks, as it dispatches to a thread pool.

Stuart

On 9 Jul. 2017 4:34 am, "SenthilKumar K" <senthilec566 at gmail.com> wrote:

Yet to try that .. My testcase  did not cover tuning no of threads .. but
even if we try to increase number of threads I believe both framework
performance would improve !! Different thoughts ??

Anyway I like to add another test case by changing threads !!

--Senthil

On Jul 8, 2017 9:38 PM, "Kim Rasmussen" <kr at asseco.dk> wrote:

> Have you tried playing around with the number of io and worker threads?
>
> l?r. 8. jul. 2017 kl. 17.28 skrev SenthilKumar K <senthilec566 at gmail.com>:
>
>> Any comments on *Undertow Vs Netty* ? Am i doing wrong benchmark testing
>>  ?? Should i change benchmark strategy ?
>>
>> --Senthil
>>
>> On Fri, Jul 7, 2017 at 3:14 PM, SenthilKumar K <senthilec566 at gmail.com>
>> wrote:
>>
>>> Sorry for delay in responding to this thread!
>>>
>>> Thanks to everyone who helped me to Optimize Undertow Server.
>>>
>>> Here is the comparison after benchmarking my use case against Netty:
>>>
>>> *Undertow Vs Netty :*
>>>
>>> Test Case 1 :
>>> Simple Request Response ( No Kafka ):
>>>
>>> *Undertow:*
>>> Running 10m test @ http://198.18.134.13:8009/
>>>   500 threads and 5000 connections
>>>   Thread Stats   Avg      Stdev     Max   +/- Stdev
>>>     Latency     *3.52m *    2.64m    8.96m    54.63%
>>>     Req/Sec   376.58    103.18     0.99k    80.53%
>>>   111628942 requests in 10.00m, 13.72GB read
>>>   Socket errors: connect 0, read 28, write 0, timeout 2
>>> Requests/sec: *186122.56*
>>> Transfer/sec:     23.43MB
>>>
>>> *Netty:*
>>> Running 10m test @ http://198.18.134.13:8009/
>>> 500 threads and 5000 connections
>>> Thread Stats   Avg      Stdev     Max   +/- Stdev
>>>     Latency     *3.77m*     2.10m    7.51m    57.73%
>>>     Req/Sec   518.63     31.78   652.00     70.25%
>>>   155406992 requests in 10.00m, 13.82GB read
>>>   Socket errors: connect 0, read 49, write 0, timeout 0
>>> Requests/sec: *259107*.30
>>> Transfer/sec:     24.17MB
>>>
>>>
>>> *Test Case 2:*
>>> Request --> Read --> Send it Kafka :
>>>
>>> *Undertow:*
>>> Running 10m test @ http://198.18.134.13:8009/
>>> 500 threads and 5000 connections
>>> Thread Stats   Avg      Stdev     Max   +/- Stdev
>>>     Latency     *4.37m *    2.46m    8.72m    57.83%
>>>     Req/Sec   267.32      5.17   287.00     74.52%
>>>   80044045 requests in 10.00m, 9.84GB read
>>>   Socket errors: connect 0, read 121, write 0, timeout 0
>>> Requests/sec: *133459.79*
>>> Transfer/sec:     16.80MB
>>>
>>> *Netty:*
>>> Running 10m test @ http://198.18.134.13:8009/
>>> 500 threads and 5000 connections
>>> Thread Stats   Avg      Stdev     Max   +/- Stdev
>>>     Latency     *3.78m *    2.10m    7.55m    57.79%
>>>     Req/Sec   516.92     28.84   642.00     69.60%
>>>   154770536 requests in 10.00m, 13.69GB read
>>>   Socket errors: connect 0, read 11, write 0, timeout 101
>>> Requests/sec: *258049.39*
>>> Transfer/sec:     23.38MB
>>>
>>>
>>>
>>> CPU Usage:
>>> *Undertow:*
>>> [image: Inline image 1]
>>>
>>> *Netty:*
>>> [image: Inline image 2]
>>>
>>>
>>> --Senthil
>>>
>>> On Thu, Jun 29, 2017 at 7:34 AM, Bill O'Neil <bill at dartalley.com> wrote:
>>>
>>>> 1. Can you run the benchmark with the kafka line commented out at first
>>>> and then again with it not commented out?
>>>> 2. What rates were you getting with Jetty and Netty?
>>>> 3. Are you running the tests from the same machine or a different one?
>>>> If its the same machine and its using 20 threads they will be contending
>>>> with undertows IO threads.
>>>> 4. You can probably ignore the POST check if thats all your going to
>>>> accept and its not a public api.
>>>>
>>>> import io.undertow.server.HttpHandler;
>>>> import io.undertow.server.HttpServerExchange;
>>>> import io.undertow.util.Headers;
>>>> import io.undertow.util.Methods;
>>>>
>>>> public class DLRHandler implements HttpHandler {
>>>>
>>>>     final public static String _SUCCESS="SUCCESS";
>>>>     final public static String _FAILURE="FAILURE";
>>>>     final PostToKafka post2Kafka = new PostToKafka();
>>>>
>>>>     @Override
>>>>     public void handleRequest( final HttpServerExchange exchange)
>>>> throws Exception {
>>>>         if (exchange.getRequestMethod().equals(Methods.POST)) {
>>>>               exchange.getRequestReceiver().receiveFullString((
>>>> exchangeReq, data) -> {
>>>>                   //post2Kafka.write2Kafka(data); // write it to Kafka
>>>>                   exchangeReq.getResponseHeaders().put(Headers.CONTENT_TYPE,
>>>> "text/plain");
>>>>                   exchangeReq.getResponseSender().send(_SUCCESS);
>>>>               },
>>>>              (exchangeReq, exception) -> {
>>>>                  exchangeReq.getResponseHeaders().put(Headers.CONTENT_TYPE,
>>>> "text/plain");
>>>>                  exchangeReq.getResponseSender().send(_FAILURE);
>>>>             });
>>>>          }else{
>>>>              throw new Exception("Method GET not supported by Server ");
>>>>          }
>>>>     }
>>>> }
>>>>
>>>> On Wed, Jun 28, 2017 at 6:59 PM, Stuart Douglas <sdouglas at redhat.com>
>>>> wrote:
>>>>
>>>>> The multiple dispatches() are unnecessary (well the second one to the
>>>>> IO thread is definitely unnecessary, the first one is only required if
>>>>> post2Kafka.write2Kafka(data); is a blocking operation and needs to be
>>>>> executed in a worker thread).
>>>>>
>>>>> Stuart
>>>>>
>>>>> On Wed, Jun 28, 2017 at 5:42 PM, SenthilKumar K <
>>>>> senthilec566 at gmail.com> wrote:
>>>>> > After modifying the code below i  could see the improvement ( not
>>>>> much
>>>>> > slightly ) in server - 65k req/sec.
>>>>> >
>>>>> > import io.undertow.server.HttpHandler;
>>>>> > import io.undertow.server.HttpServerExchange;
>>>>> > import io.undertow.util.Headers;
>>>>> > import io.undertow.util.Methods;
>>>>> >
>>>>> > public class DLRHandler implements HttpHandler {
>>>>> >
>>>>> >     final public static String _SUCCESS="SUCCESS";
>>>>> >     final public static String _FAILURE="FAILURE";
>>>>> >     final PostToKafka post2Kafka = new PostToKafka();
>>>>> >
>>>>> >     @Override
>>>>> >     public void handleRequest( final HttpServerExchange exchange)
>>>>> throws
>>>>> > Exception {
>>>>> >         if (exchange.getRequestMethod().equals(Methods.POST)) {
>>>>> >                 exchange.getRequestReceiver().receiveFullString((
>>>>> > exchangeReq, data) -> {
>>>>> >                   exchangeReq.dispatch(() -> {
>>>>> >                       post2Kafka.write2Kafka(data); // write it to
>>>>> Kafka
>>>>> >                       exchangeReq.dispatch(exchangeReq.getIoThread(),
>>>>> () ->
>>>>> > {
>>>>> >
>>>>> > exchangeReq.getResponseHeaders().put(Headers.CONTENT_TYPE,
>>>>> "text/plain");
>>>>> >                           exchangeReq.getResponseSender
>>>>> ().send(_SUCCESS);
>>>>> >                       });
>>>>> >                   });
>>>>> >               },
>>>>> >              (exchangeReq, exception) -> {
>>>>> >                  exchangeReq.getResponseHeaders
>>>>> ().put(Headers.CONTENT_TYPE,
>>>>> > "text/plain");
>>>>> >                  exchangeReq.getResponseSender().send(_FAILURE);
>>>>> >             });
>>>>> >          }else{
>>>>> >              throw new Exception("Method GET not supported by Server
>>>>> ");
>>>>> >          }
>>>>> >     }
>>>>> > }
>>>>> >
>>>>> >
>>>>> > Pls review this and let me know if i'm doing anything wrong here ...
>>>>> > --Senthil
>>>>> >
>>>>> > On Fri, Jun 23, 2017 at 1:30 PM, Antoine Girard <
>>>>> antoine.girard at ymail.com>
>>>>> > wrote:
>>>>> >>
>>>>> >> Also, to come back on the JVM warmup, this will give you enough
>>>>> answers:
>>>>> >>
>>>>> >> https://stackoverflow.com/questions/36198278/why-does-the-
>>>>> jvm-require-warmup
>>>>> >>
>>>>> >> For your, it means that you have to run your tests for a few minutes
>>>>> >> before starting your actual measurements.
>>>>> >>
>>>>> >> I am also interested about how Netty / Jetty perform under the same
>>>>> >> conditions, please post!
>>>>> >>
>>>>> >> Cheers,
>>>>> >> Antoine
>>>>> >>
>>>>> >> On Fri, Jun 23, 2017 at 1:24 AM, Stuart Douglas <
>>>>> sdouglas at redhat.com>
>>>>> >> wrote:
>>>>> >>>
>>>>> >>> Are you actually testing with the 'System.out.println(" Received
>>>>> >>> String ==> "+message);'. System.out is incredibly slow.
>>>>> >>>
>>>>> >>> Stuart
>>>>> >>>
>>>>> >>> On Fri, Jun 23, 2017 at 7:01 AM, SenthilKumar K <
>>>>> senthilec566 at gmail.com>
>>>>> >>> wrote:
>>>>> >>> > Sorry , I'm not an expert in JVM .. How do we do Warm Up JVM ?
>>>>> >>> >
>>>>> >>> > Here is the JVM args to Server:
>>>>> >>> >
>>>>> >>> > nohup java -Xmx4g -Xms4g -XX:MetaspaceSize=96m -XX:+UseG1GC
>>>>> >>> > -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35
>>>>> >>> > -XX:G1HeapRegionSize=16M -XX:MinMetaspaceFreeRatio=50
>>>>> >>> > -XX:MaxMetaspaceFreeRatio=80 -cp undertow-0.0.1.jar
>>>>> HelloWorldServer
>>>>> >>> >
>>>>> >>> >
>>>>> >>> > --Senthil
>>>>> >>> >
>>>>> >>> >
>>>>> >>> > On Fri, Jun 23, 2017 at 2:23 AM, Antoine Girard
>>>>> >>> > <antoine.girard at ymail.com>
>>>>> >>> > wrote:
>>>>> >>> >>
>>>>> >>> >> Do you warm up your jvm prior to the testing?
>>>>> >>> >>
>>>>> >>> >> Cheers,
>>>>> >>> >> Antoine
>>>>> >>> >>
>>>>> >>> >> On Thu, Jun 22, 2017 at 10:42 PM, SenthilKumar K
>>>>> >>> >> <senthilec566 at gmail.com>
>>>>> >>> >> wrote:
>>>>> >>> >>>
>>>>> >>> >>> Thanks Bill n Antoine ..
>>>>> >>> >>>
>>>>> >>> >>>
>>>>> >>> >>> Here is the updated one : ( tried without Kafka API ) .
>>>>> >>> >>>
>>>>> >>> >>> public class HelloWorldServer {
>>>>> >>> >>>
>>>>> >>> >>> public static void main(final String[] args) {
>>>>> >>> >>> Undertow server = Undertow.builder().addHttpListener(8009,
>>>>> >>> >>> "localhost").setHandler(new HttpHandler() {
>>>>> >>> >>> @Override
>>>>> >>> >>> public void handleRequest(final HttpServerExchange exchange)
>>>>> throws
>>>>> >>> >>> Exception {
>>>>> >>> >>> if (exchange.getRequestMethod().equals(Methods.POST)) {
>>>>> >>> >>> exchange.getRequestReceiver().receiveFullString(new
>>>>> >>> >>> Receiver.FullStringCallback() {
>>>>> >>> >>>                    @Override
>>>>> >>> >>>                    public void handle(HttpServerExchange
>>>>> exchange,
>>>>> >>> >>> String
>>>>> >>> >>> message) {
>>>>> >>> >>>                     System.out.println(" Received String ==>
>>>>> >>> >>> "+message);
>>>>> >>> >>>                        exchange.getResponseSender().s
>>>>> end(message);
>>>>> >>> >>>                    }
>>>>> >>> >>>                });
>>>>> >>> >>> } else {
>>>>> >>> >>> exchange.getResponseHeaders().put(Headers.CONTENT_TYPE,
>>>>> >>> >>> "text/plain");
>>>>> >>> >>> exchange.getResponseSender().send("FAILURE");
>>>>> >>> >>> }
>>>>> >>> >>> }
>>>>> >>> >>> }).build();
>>>>> >>> >>> server.start();
>>>>> >>> >>> }
>>>>> >>> >>> }
>>>>> >>> >>>
>>>>> >>> >>>
>>>>> >>> >>> Oops seems to no improvement :
>>>>> >>> >>>
>>>>> >>> >>> Running 1m test @ http://localhost:8009/
>>>>> >>> >>>   100 threads and 1000 connections
>>>>> >>> >>>   Thread Stats   Avg      Stdev     Max   +/- Stdev
>>>>> >>> >>>     Latency    25.79ms   22.18ms 289.48ms   67.66%
>>>>> >>> >>>     Req/Sec   437.76     61.71     2.30k    80.26%
>>>>> >>> >>>   Latency Distribution
>>>>> >>> >>>      50%   22.60ms
>>>>> >>> >>>      75%   37.83ms
>>>>> >>> >>>      90%   55.32ms
>>>>> >>> >>>      99%   90.47ms
>>>>> >>> >>>   2625607 requests in 1.00m, 2.76GB read
>>>>> >>> >>> Requests/sec:  43688.42
>>>>> >>> >>> Transfer/sec:     47.08MB
>>>>> >>> >>>
>>>>> >>> >>>
>>>>> >>> >>> :-( :-( ..
>>>>> >>> >>>
>>>>> >>> >>>
>>>>> >>> >>> --Senthil
>>>>> >>> >>>
>>>>> >>> >>>
>>>>> >>> >>> On Fri, Jun 23, 2017 at 1:47 AM, Antoine Girard
>>>>> >>> >>> <antoine.girard at ymail.com> wrote:
>>>>> >>> >>>>
>>>>> >>> >>>> You can use the Receiver API, specifically for that purpose.
>>>>> >>> >>>> On the exchange, call: getRequestReceiver();
>>>>> >>> >>>>
>>>>> >>> >>>> You will get a receiver object:
>>>>> >>> >>>>
>>>>> >>> >>>>
>>>>> >>> >>>> https://github.com/undertow-io/undertow/blob/master/core/src
>>>>> /main/java/io/undertow/io/Receiver.java
>>>>> >>> >>>>
>>>>> >>> >>>> On the receiver you can call: receiveFullString, you have to
>>>>> pass it
>>>>> >>> >>>> a
>>>>> >>> >>>> callback that will be called when the whole body has been
>>>>> read.
>>>>> >>> >>>>
>>>>> >>> >>>> Please share your results when you test this further!
>>>>> >>> >>>>
>>>>> >>> >>>> Cheers,
>>>>> >>> >>>> Antoine
>>>>> >>> >>>>
>>>>> >>> >>>>
>>>>> >>> >>>> On Thu, Jun 22, 2017 at 8:27 PM, SenthilKumar K
>>>>> >>> >>>> <senthilec566 at gmail.com>
>>>>> >>> >>>> wrote:
>>>>> >>> >>>>>
>>>>> >>> >>>>> Seems to Reading Request body is wrong , So what is the
>>>>> efficient
>>>>> >>> >>>>> way
>>>>> >>> >>>>> of reading request body in undertow ?
>>>>> >>> >>>>>
>>>>> >>> >>>>> --Senthil
>>>>> >>> >>>>>
>>>>> >>> >>>>> On Thu, Jun 22, 2017 at 11:30 PM, SenthilKumar K
>>>>> >>> >>>>> <senthilec566 at gmail.com> wrote:
>>>>> >>> >>>>>>
>>>>> >>> >>>>>> Hello Undertow Dev Team ,
>>>>> >>> >>>>>>
>>>>> >>> >>>>>>       I have been working on the use case where i should
>>>>> create
>>>>> >>> >>>>>> simple
>>>>> >>> >>>>>> http server to serve 1.5 Million Requests per Second per
>>>>> Instance
>>>>> >>> >>>>>> ..
>>>>> >>> >>>>>>
>>>>> >>> >>>>>>
>>>>> >>> >>>>>> Here is the benchmark result of Undertow :
>>>>> >>> >>>>>>
>>>>> >>> >>>>>> Running 1m test @ http://127.0.0.1:8009/
>>>>> >>> >>>>>>   20 threads and 40 connections
>>>>> >>> >>>>>>   Thread Stats   Avg      Stdev     Max   +/- Stdev
>>>>> >>> >>>>>>     Latency     2.51ms   10.75ms 282.22ms   99.28%
>>>>> >>> >>>>>>     Req/Sec     1.12k   316.65     1.96k    54.50%
>>>>> >>> >>>>>>   Latency Distribution
>>>>> >>> >>>>>>      50%    1.43ms
>>>>> >>> >>>>>>      75%    2.38ms
>>>>> >>> >>>>>>      90%    2.90ms
>>>>> >>> >>>>>>      99%   10.45ms
>>>>> >>> >>>>>>   1328133 requests in 1.00m, 167.19MB read
>>>>> >>> >>>>>> Requests/sec:  22127.92
>>>>> >>> >>>>>> Transfer/sec:      2.79MB
>>>>> >>> >>>>>>
>>>>> >>> >>>>>> This is less compared to other frameworks like Jetty and
>>>>> Netty ..
>>>>> >>> >>>>>> But
>>>>> >>> >>>>>> originally Undertow is high performant http server ..
>>>>> >>> >>>>>>
>>>>> >>> >>>>>> Hardware details:
>>>>> >>> >>>>>> Xeon CPU E3-1270 v5 machine with 4 cores ( Clock 100 MHz,
>>>>> Capacity
>>>>> >>> >>>>>> 4
>>>>> >>> >>>>>> GHz) , Memory : 32 G , Available memory 31 G.
>>>>> >>> >>>>>>
>>>>> >>> >>>>>> I would need Undertow experts to review the server code
>>>>> below and
>>>>> >>> >>>>>> advice me on tuning to achieve my goal( ~1.5 Million
>>>>> requests/sec
>>>>> >>> >>>>>> ).
>>>>> >>> >>>>>>
>>>>> >>> >>>>>> Server :
>>>>> >>> >>>>>>
>>>>> >>> >>>>>> Undertow server = Undertow.builder()
>>>>> >>> >>>>>>                .addHttpListener(8009, "localhost")
>>>>> >>> >>>>>>                .setHandler(new Handler()).build();
>>>>> >>> >>>>>> server.start();
>>>>> >>> >>>>>>
>>>>> >>> >>>>>>
>>>>> >>> >>>>>> Handler.Java
>>>>> >>> >>>>>>
>>>>> >>> >>>>>>     final Pooled<ByteBuffer> pooledByteBuffer =
>>>>> >>> >>>>>>
>>>>> >>> >>>>>> exchange.getConnection().getBufferPool().allocate();
>>>>> >>> >>>>>> final ByteBuffer byteBuffer = pooledByteBuffer.getResource()
>>>>> ;
>>>>> >>> >>>>>>    byteBuffer.clear();
>>>>> >>> >>>>>>    exchange.getRequestChannel().read(byteBuffer);
>>>>> >>> >>>>>>    int pos = byteBuffer.position();
>>>>> >>> >>>>>>    byteBuffer.rewind();
>>>>> >>> >>>>>>    byte[] bytes = new byte[pos];
>>>>> >>> >>>>>>    byteBuffer.get(bytes);
>>>>> >>> >>>>>>    String requestBody = new String(bytes,
>>>>> Charset.forName("UTF-8")
>>>>> >>> >>>>>> );
>>>>> >>> >>>>>>    byteBuffer.clear();
>>>>> >>> >>>>>>    pooledByteBuffer.free();
>>>>> >>> >>>>>>    final PostToKafka post2Kafka = new PostToKafka();
>>>>> >>> >>>>>> try {
>>>>> >>> >>>>>> post2Kafka.write2Kafka(requestBody);  { This API can
>>>>> handle  ~2
>>>>> >>> >>>>>> Millions events per sec }
>>>>> >>> >>>>>> } catch (Exception e) {
>>>>> >>> >>>>>> e.printStackTrace();
>>>>> >>> >>>>>> }
>>>>> >>> >>>>>>     exchange.getResponseHeaders().put(Headers.CONTENT_TYPE,
>>>>> >>> >>>>>> "text/plain");
>>>>> >>> >>>>>>     exchange.getResponseSender().send("SUCCESS");
>>>>> >>> >>>>>>
>>>>> >>> >>>>>>
>>>>> >>> >>>>>> --Senthil
>>>>> >>> >>>>>
>>>>> >>> >>>>>
>>>>> >>> >>>>>
>>>>> >>> >>>>> _______________________________________________
>>>>> >>> >>>>> 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
>>>>>
>>>>
>>>>
>>>
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
> --
> Med venlig hilsen / Best regards
>
> *Kim Rasmussen*
> Partner, IT Architect
>
> *Asseco Denmark A/S*
> Kronprinsessegade 54
> DK-1306 Copenhagen K
> Mobile: +45 26 16 40 23 <+45%2026%2016%2040%2023>
> Ph.: +45 33 36 46 60 <+45%2033%2036%2046%2060>
> Fax: +45 33 36 46 61 <+45%2033%2036%2046%2061>
>

_______________________________________________
undertow-dev mailing list
undertow-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170710/0f33a63e/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 31196 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20170710/0f33a63e/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 25115 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20170710/0f33a63e/attachment-0003.png 

From sdouglas at redhat.com  Sun Jul  9 17:42:01 2017
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 10 Jul 2017 09:42:01 +1200
Subject: [undertow-dev] Undertow Http Server - Handling 2 Millions
 Requests Per Second Per Instance
In-Reply-To: <CAD+L2cwuxju5Q0e0NG+Soaxz6evfALsN-KLvw-1haTucPL4XtQ@mail.gmail.com>
References: <CA+xmZH2ChvRWQGK4X-oFmzxdTzq7R2W7GPv0t=2VrkKDW2a6TQ@mail.gmail.com>
	<CA+xmZH1UDdugtkDvxTp9KdL_h2UtP7QRrz5As-KRj6M8W3DM1g@mail.gmail.com>
	<CALc5U3Fy1POagBsY39aMOtbFjJYRYN0SQs8cTu=jovxtxGx6DA@mail.gmail.com>
	<CA+xmZH3nLf_-JhdYGcbSpB4LzhkHSni3n+OTgj=J9WM=t1YQ6w@mail.gmail.com>
	<CALc5U3F_kYOiNsA9P28EyJM_utqm5LmmZiKusNLQQnobM0TLVg@mail.gmail.com>
	<CA+xmZH3fOcO3L6ztGiqty33jeeXeJjmjGKVqBCXzB3NdkpA2Pg@mail.gmail.com>
	<CAD+L2cw-KCPNCy-+fYheUMTMmj-7+GdAi9y568HcTWKoBX5aOg@mail.gmail.com>
	<CALc5U3HdmPTSeePwft-zc2hRELvim8Rpbr05QYaR-6prpGUo4A@mail.gmail.com>
	<CA+xmZH0OTSpTYhvk94Xt2B66-BaAFKWNNp7YbBbj4+ZQ6ZB9GQ@mail.gmail.com>
	<CAD+L2cy-w8xsu5q2y7vTQzFSy_9V9Jm1X=EaALV6QYp3dVS++A@mail.gmail.com>
	<CANd+gFx4WLY54cPirYOc6PiRByY01HAKLVX0XiEEFOBmae5zxg@mail.gmail.com>
	<CA+xmZH12c=meg-wv982jAF-tX_5etmq66LVa0VOkB3HhM_ZL-g@mail.gmail.com>
	<CA+xmZH2p09d_8Pn+Nsje2sndCbwuj8e7FN95Bq78p+JYUZfWKg@mail.gmail.com>
	<CAGX6Y=1vJR_gZ_PzutBPo7+LcrXwdJF+fdhzpfOfg0FTe9Ugrg@mail.gmail.com>
	<CA+xmZH1dvBrEft3ERNe6kpVGgO=R2D0ciqjwKLjQ_GcXhMFrWA@mail.gmail.com>
	<CAD+L2cwuxju5Q0e0NG+Soaxz6evfALsN-KLvw-1haTucPL4XtQ@mail.gmail.com>
Message-ID: <CAD+L2cxNnuArSxSbyszSESwZfJi8Yf6Zj1JPCwEyO+4XaVUOYw@mail.gmail.com>

Also it looks like you are sending more data in the undertow response. Mb/s
is very similar, while req/sec is lower.

Stuart

On 10 Jul. 2017 9:39 am, "Stuart Douglas" <sdouglas at redhat.com> wrote:

> Are they both using the same number of threads? Also what are you doing in
> the handler? Are you calling dispatch? Dispatch is relativity slow in these
> micro benchmarks, as it dispatches to a thread pool.
>
> Stuart
>
> On 9 Jul. 2017 4:34 am, "SenthilKumar K" <senthilec566 at gmail.com> wrote:
>
> Yet to try that .. My testcase  did not cover tuning no of threads .. but
> even if we try to increase number of threads I believe both framework
> performance would improve !! Different thoughts ??
>
> Anyway I like to add another test case by changing threads !!
>
> --Senthil
>
> On Jul 8, 2017 9:38 PM, "Kim Rasmussen" <kr at asseco.dk> wrote:
>
>> Have you tried playing around with the number of io and worker threads?
>>
>> l?r. 8. jul. 2017 kl. 17.28 skrev SenthilKumar K <senthilec566 at gmail.com
>> >:
>>
>>> Any comments on *Undertow Vs Netty* ? Am i doing wrong benchmark
>>> testing  ?? Should i change benchmark strategy ?
>>>
>>> --Senthil
>>>
>>> On Fri, Jul 7, 2017 at 3:14 PM, SenthilKumar K <senthilec566 at gmail.com>
>>> wrote:
>>>
>>>> Sorry for delay in responding to this thread!
>>>>
>>>> Thanks to everyone who helped me to Optimize Undertow Server.
>>>>
>>>> Here is the comparison after benchmarking my use case against Netty:
>>>>
>>>> *Undertow Vs Netty :*
>>>>
>>>> Test Case 1 :
>>>> Simple Request Response ( No Kafka ):
>>>>
>>>> *Undertow:*
>>>> Running 10m test @ http://198.18.134.13:8009/
>>>>   500 threads and 5000 connections
>>>>   Thread Stats   Avg      Stdev     Max   +/- Stdev
>>>>     Latency     *3.52m *    2.64m    8.96m    54.63%
>>>>     Req/Sec   376.58    103.18     0.99k    80.53%
>>>>   111628942 requests in 10.00m, 13.72GB read
>>>>   Socket errors: connect 0, read 28, write 0, timeout 2
>>>> Requests/sec: *186122.56*
>>>> Transfer/sec:     23.43MB
>>>>
>>>> *Netty:*
>>>> Running 10m test @ http://198.18.134.13:8009/
>>>> 500 threads and 5000 connections
>>>> Thread Stats   Avg      Stdev     Max   +/- Stdev
>>>>     Latency     *3.77m*     2.10m    7.51m    57.73%
>>>>     Req/Sec   518.63     31.78   652.00     70.25%
>>>>   155406992 requests in 10.00m, 13.82GB read
>>>>   Socket errors: connect 0, read 49, write 0, timeout 0
>>>> Requests/sec: *259107*.30
>>>> Transfer/sec:     24.17MB
>>>>
>>>>
>>>> *Test Case 2:*
>>>> Request --> Read --> Send it Kafka :
>>>>
>>>> *Undertow:*
>>>> Running 10m test @ http://198.18.134.13:8009/
>>>> 500 threads and 5000 connections
>>>> Thread Stats   Avg      Stdev     Max   +/- Stdev
>>>>     Latency     *4.37m *    2.46m    8.72m    57.83%
>>>>     Req/Sec   267.32      5.17   287.00     74.52%
>>>>   80044045 requests in 10.00m, 9.84GB read
>>>>   Socket errors: connect 0, read 121, write 0, timeout 0
>>>> Requests/sec: *133459.79*
>>>> Transfer/sec:     16.80MB
>>>>
>>>> *Netty:*
>>>> Running 10m test @ http://198.18.134.13:8009/
>>>> 500 threads and 5000 connections
>>>> Thread Stats   Avg      Stdev     Max   +/- Stdev
>>>>     Latency     *3.78m *    2.10m    7.55m    57.79%
>>>>     Req/Sec   516.92     28.84   642.00     69.60%
>>>>   154770536 requests in 10.00m, 13.69GB read
>>>>   Socket errors: connect 0, read 11, write 0, timeout 101
>>>> Requests/sec: *258049.39*
>>>> Transfer/sec:     23.38MB
>>>>
>>>>
>>>>
>>>> CPU Usage:
>>>> *Undertow:*
>>>> [image: Inline image 1]
>>>>
>>>> *Netty:*
>>>> [image: Inline image 2]
>>>>
>>>>
>>>> --Senthil
>>>>
>>>> On Thu, Jun 29, 2017 at 7:34 AM, Bill O'Neil <bill at dartalley.com>
>>>> wrote:
>>>>
>>>>> 1. Can you run the benchmark with the kafka line commented out at
>>>>> first and then again with it not commented out?
>>>>> 2. What rates were you getting with Jetty and Netty?
>>>>> 3. Are you running the tests from the same machine or a different one?
>>>>> If its the same machine and its using 20 threads they will be contending
>>>>> with undertows IO threads.
>>>>> 4. You can probably ignore the POST check if thats all your going to
>>>>> accept and its not a public api.
>>>>>
>>>>> import io.undertow.server.HttpHandler;
>>>>> import io.undertow.server.HttpServerExchange;
>>>>> import io.undertow.util.Headers;
>>>>> import io.undertow.util.Methods;
>>>>>
>>>>> public class DLRHandler implements HttpHandler {
>>>>>
>>>>>     final public static String _SUCCESS="SUCCESS";
>>>>>     final public static String _FAILURE="FAILURE";
>>>>>     final PostToKafka post2Kafka = new PostToKafka();
>>>>>
>>>>>     @Override
>>>>>     public void handleRequest( final HttpServerExchange exchange)
>>>>> throws Exception {
>>>>>         if (exchange.getRequestMethod().equals(Methods.POST)) {
>>>>>               exchange.getRequestReceiver().receiveFullString((
>>>>> exchangeReq, data) -> {
>>>>>                   //post2Kafka.write2Kafka(data); // write it to Kafka
>>>>>                   exchangeReq.getResponseHeaders().put(Headers.CONTENT_TYPE,
>>>>> "text/plain");
>>>>>                   exchangeReq.getResponseSender().send(_SUCCESS);
>>>>>               },
>>>>>              (exchangeReq, exception) -> {
>>>>>                  exchangeReq.getResponseHeaders().put(Headers.CONTENT_TYPE,
>>>>> "text/plain");
>>>>>                  exchangeReq.getResponseSender().send(_FAILURE);
>>>>>             });
>>>>>          }else{
>>>>>              throw new Exception("Method GET not supported by Server
>>>>> ");
>>>>>          }
>>>>>     }
>>>>> }
>>>>>
>>>>> On Wed, Jun 28, 2017 at 6:59 PM, Stuart Douglas <sdouglas at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> The multiple dispatches() are unnecessary (well the second one to the
>>>>>> IO thread is definitely unnecessary, the first one is only required if
>>>>>> post2Kafka.write2Kafka(data); is a blocking operation and needs to be
>>>>>> executed in a worker thread).
>>>>>>
>>>>>> Stuart
>>>>>>
>>>>>> On Wed, Jun 28, 2017 at 5:42 PM, SenthilKumar K <
>>>>>> senthilec566 at gmail.com> wrote:
>>>>>> > After modifying the code below i  could see the improvement ( not
>>>>>> much
>>>>>> > slightly ) in server - 65k req/sec.
>>>>>> >
>>>>>> > import io.undertow.server.HttpHandler;
>>>>>> > import io.undertow.server.HttpServerExchange;
>>>>>> > import io.undertow.util.Headers;
>>>>>> > import io.undertow.util.Methods;
>>>>>> >
>>>>>> > public class DLRHandler implements HttpHandler {
>>>>>> >
>>>>>> >     final public static String _SUCCESS="SUCCESS";
>>>>>> >     final public static String _FAILURE="FAILURE";
>>>>>> >     final PostToKafka post2Kafka = new PostToKafka();
>>>>>> >
>>>>>> >     @Override
>>>>>> >     public void handleRequest( final HttpServerExchange exchange)
>>>>>> throws
>>>>>> > Exception {
>>>>>> >         if (exchange.getRequestMethod().equals(Methods.POST)) {
>>>>>> >                 exchange.getRequestReceiver().receiveFullString((
>>>>>> > exchangeReq, data) -> {
>>>>>> >                   exchangeReq.dispatch(() -> {
>>>>>> >                       post2Kafka.write2Kafka(data); // write it to
>>>>>> Kafka
>>>>>> >                       exchangeReq.dispatch(exchangeReq.getIoThread(),
>>>>>> () ->
>>>>>> > {
>>>>>> >
>>>>>> > exchangeReq.getResponseHeaders().put(Headers.CONTENT_TYPE,
>>>>>> "text/plain");
>>>>>> >                           exchangeReq.getResponseSender
>>>>>> ().send(_SUCCESS);
>>>>>> >                       });
>>>>>> >                   });
>>>>>> >               },
>>>>>> >              (exchangeReq, exception) -> {
>>>>>> >                  exchangeReq.getResponseHeaders
>>>>>> ().put(Headers.CONTENT_TYPE,
>>>>>> > "text/plain");
>>>>>> >                  exchangeReq.getResponseSender().send(_FAILURE);
>>>>>> >             });
>>>>>> >          }else{
>>>>>> >              throw new Exception("Method GET not supported by
>>>>>> Server ");
>>>>>> >          }
>>>>>> >     }
>>>>>> > }
>>>>>> >
>>>>>> >
>>>>>> > Pls review this and let me know if i'm doing anything wrong here ...
>>>>>> > --Senthil
>>>>>> >
>>>>>> > On Fri, Jun 23, 2017 at 1:30 PM, Antoine Girard <
>>>>>> antoine.girard at ymail.com>
>>>>>> > wrote:
>>>>>> >>
>>>>>> >> Also, to come back on the JVM warmup, this will give you enough
>>>>>> answers:
>>>>>> >>
>>>>>> >> https://stackoverflow.com/questions/36198278/why-does-the-jv
>>>>>> m-require-warmup
>>>>>> >>
>>>>>> >> For your, it means that you have to run your tests for a few
>>>>>> minutes
>>>>>> >> before starting your actual measurements.
>>>>>> >>
>>>>>> >> I am also interested about how Netty / Jetty perform under the same
>>>>>> >> conditions, please post!
>>>>>> >>
>>>>>> >> Cheers,
>>>>>> >> Antoine
>>>>>> >>
>>>>>> >> On Fri, Jun 23, 2017 at 1:24 AM, Stuart Douglas <
>>>>>> sdouglas at redhat.com>
>>>>>> >> wrote:
>>>>>> >>>
>>>>>> >>> Are you actually testing with the 'System.out.println(" Received
>>>>>> >>> String ==> "+message);'. System.out is incredibly slow.
>>>>>> >>>
>>>>>> >>> Stuart
>>>>>> >>>
>>>>>> >>> On Fri, Jun 23, 2017 at 7:01 AM, SenthilKumar K <
>>>>>> senthilec566 at gmail.com>
>>>>>> >>> wrote:
>>>>>> >>> > Sorry , I'm not an expert in JVM .. How do we do Warm Up JVM ?
>>>>>> >>> >
>>>>>> >>> > Here is the JVM args to Server:
>>>>>> >>> >
>>>>>> >>> > nohup java -Xmx4g -Xms4g -XX:MetaspaceSize=96m -XX:+UseG1GC
>>>>>> >>> > -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35
>>>>>> >>> > -XX:G1HeapRegionSize=16M -XX:MinMetaspaceFreeRatio=50
>>>>>> >>> > -XX:MaxMetaspaceFreeRatio=80 -cp undertow-0.0.1.jar
>>>>>> HelloWorldServer
>>>>>> >>> >
>>>>>> >>> >
>>>>>> >>> > --Senthil
>>>>>> >>> >
>>>>>> >>> >
>>>>>> >>> > On Fri, Jun 23, 2017 at 2:23 AM, Antoine Girard
>>>>>> >>> > <antoine.girard at ymail.com>
>>>>>> >>> > wrote:
>>>>>> >>> >>
>>>>>> >>> >> Do you warm up your jvm prior to the testing?
>>>>>> >>> >>
>>>>>> >>> >> Cheers,
>>>>>> >>> >> Antoine
>>>>>> >>> >>
>>>>>> >>> >> On Thu, Jun 22, 2017 at 10:42 PM, SenthilKumar K
>>>>>> >>> >> <senthilec566 at gmail.com>
>>>>>> >>> >> wrote:
>>>>>> >>> >>>
>>>>>> >>> >>> Thanks Bill n Antoine ..
>>>>>> >>> >>>
>>>>>> >>> >>>
>>>>>> >>> >>> Here is the updated one : ( tried without Kafka API ) .
>>>>>> >>> >>>
>>>>>> >>> >>> public class HelloWorldServer {
>>>>>> >>> >>>
>>>>>> >>> >>> public static void main(final String[] args) {
>>>>>> >>> >>> Undertow server = Undertow.builder().addHttpListener(8009,
>>>>>> >>> >>> "localhost").setHandler(new HttpHandler() {
>>>>>> >>> >>> @Override
>>>>>> >>> >>> public void handleRequest(final HttpServerExchange exchange)
>>>>>> throws
>>>>>> >>> >>> Exception {
>>>>>> >>> >>> if (exchange.getRequestMethod().equals(Methods.POST)) {
>>>>>> >>> >>> exchange.getRequestReceiver().receiveFullString(new
>>>>>> >>> >>> Receiver.FullStringCallback() {
>>>>>> >>> >>>                    @Override
>>>>>> >>> >>>                    public void handle(HttpServerExchange
>>>>>> exchange,
>>>>>> >>> >>> String
>>>>>> >>> >>> message) {
>>>>>> >>> >>>                     System.out.println(" Received String ==>
>>>>>> >>> >>> "+message);
>>>>>> >>> >>>                        exchange.getResponseSender().s
>>>>>> end(message);
>>>>>> >>> >>>                    }
>>>>>> >>> >>>                });
>>>>>> >>> >>> } else {
>>>>>> >>> >>> exchange.getResponseHeaders().put(Headers.CONTENT_TYPE,
>>>>>> >>> >>> "text/plain");
>>>>>> >>> >>> exchange.getResponseSender().send("FAILURE");
>>>>>> >>> >>> }
>>>>>> >>> >>> }
>>>>>> >>> >>> }).build();
>>>>>> >>> >>> server.start();
>>>>>> >>> >>> }
>>>>>> >>> >>> }
>>>>>> >>> >>>
>>>>>> >>> >>>
>>>>>> >>> >>> Oops seems to no improvement :
>>>>>> >>> >>>
>>>>>> >>> >>> Running 1m test @ http://localhost:8009/
>>>>>> >>> >>>   100 threads and 1000 connections
>>>>>> >>> >>>   Thread Stats   Avg      Stdev     Max   +/- Stdev
>>>>>> >>> >>>     Latency    25.79ms   22.18ms 289.48ms   67.66%
>>>>>> >>> >>>     Req/Sec   437.76     61.71     2.30k    80.26%
>>>>>> >>> >>>   Latency Distribution
>>>>>> >>> >>>      50%   22.60ms
>>>>>> >>> >>>      75%   37.83ms
>>>>>> >>> >>>      90%   55.32ms
>>>>>> >>> >>>      99%   90.47ms
>>>>>> >>> >>>   2625607 requests in 1.00m, 2.76GB read
>>>>>> >>> >>> Requests/sec:  43688.42
>>>>>> >>> >>> Transfer/sec:     47.08MB
>>>>>> >>> >>>
>>>>>> >>> >>>
>>>>>> >>> >>> :-( :-( ..
>>>>>> >>> >>>
>>>>>> >>> >>>
>>>>>> >>> >>> --Senthil
>>>>>> >>> >>>
>>>>>> >>> >>>
>>>>>> >>> >>> On Fri, Jun 23, 2017 at 1:47 AM, Antoine Girard
>>>>>> >>> >>> <antoine.girard at ymail.com> wrote:
>>>>>> >>> >>>>
>>>>>> >>> >>>> You can use the Receiver API, specifically for that purpose.
>>>>>> >>> >>>> On the exchange, call: getRequestReceiver();
>>>>>> >>> >>>>
>>>>>> >>> >>>> You will get a receiver object:
>>>>>> >>> >>>>
>>>>>> >>> >>>>
>>>>>> >>> >>>> https://github.com/undertow-io/undertow/blob/master/core/src
>>>>>> /main/java/io/undertow/io/Receiver.java
>>>>>> >>> >>>>
>>>>>> >>> >>>> On the receiver you can call: receiveFullString, you have to
>>>>>> pass it
>>>>>> >>> >>>> a
>>>>>> >>> >>>> callback that will be called when the whole body has been
>>>>>> read.
>>>>>> >>> >>>>
>>>>>> >>> >>>> Please share your results when you test this further!
>>>>>> >>> >>>>
>>>>>> >>> >>>> Cheers,
>>>>>> >>> >>>> Antoine
>>>>>> >>> >>>>
>>>>>> >>> >>>>
>>>>>> >>> >>>> On Thu, Jun 22, 2017 at 8:27 PM, SenthilKumar K
>>>>>> >>> >>>> <senthilec566 at gmail.com>
>>>>>> >>> >>>> wrote:
>>>>>> >>> >>>>>
>>>>>> >>> >>>>> Seems to Reading Request body is wrong , So what is the
>>>>>> efficient
>>>>>> >>> >>>>> way
>>>>>> >>> >>>>> of reading request body in undertow ?
>>>>>> >>> >>>>>
>>>>>> >>> >>>>> --Senthil
>>>>>> >>> >>>>>
>>>>>> >>> >>>>> On Thu, Jun 22, 2017 at 11:30 PM, SenthilKumar K
>>>>>> >>> >>>>> <senthilec566 at gmail.com> wrote:
>>>>>> >>> >>>>>>
>>>>>> >>> >>>>>> Hello Undertow Dev Team ,
>>>>>> >>> >>>>>>
>>>>>> >>> >>>>>>       I have been working on the use case where i should
>>>>>> create
>>>>>> >>> >>>>>> simple
>>>>>> >>> >>>>>> http server to serve 1.5 Million Requests per Second per
>>>>>> Instance
>>>>>> >>> >>>>>> ..
>>>>>> >>> >>>>>>
>>>>>> >>> >>>>>>
>>>>>> >>> >>>>>> Here is the benchmark result of Undertow :
>>>>>> >>> >>>>>>
>>>>>> >>> >>>>>> Running 1m test @ http://127.0.0.1:8009/
>>>>>> >>> >>>>>>   20 threads and 40 connections
>>>>>> >>> >>>>>>   Thread Stats   Avg      Stdev     Max   +/- Stdev
>>>>>> >>> >>>>>>     Latency     2.51ms   10.75ms 282.22ms   99.28%
>>>>>> >>> >>>>>>     Req/Sec     1.12k   316.65     1.96k    54.50%
>>>>>> >>> >>>>>>   Latency Distribution
>>>>>> >>> >>>>>>      50%    1.43ms
>>>>>> >>> >>>>>>      75%    2.38ms
>>>>>> >>> >>>>>>      90%    2.90ms
>>>>>> >>> >>>>>>      99%   10.45ms
>>>>>> >>> >>>>>>   1328133 requests in 1.00m, 167.19MB read
>>>>>> >>> >>>>>> Requests/sec:  22127.92
>>>>>> >>> >>>>>> Transfer/sec:      2.79MB
>>>>>> >>> >>>>>>
>>>>>> >>> >>>>>> This is less compared to other frameworks like Jetty and
>>>>>> Netty ..
>>>>>> >>> >>>>>> But
>>>>>> >>> >>>>>> originally Undertow is high performant http server ..
>>>>>> >>> >>>>>>
>>>>>> >>> >>>>>> Hardware details:
>>>>>> >>> >>>>>> Xeon CPU E3-1270 v5 machine with 4 cores ( Clock 100 MHz,
>>>>>> Capacity
>>>>>> >>> >>>>>> 4
>>>>>> >>> >>>>>> GHz) , Memory : 32 G , Available memory 31 G.
>>>>>> >>> >>>>>>
>>>>>> >>> >>>>>> I would need Undertow experts to review the server code
>>>>>> below and
>>>>>> >>> >>>>>> advice me on tuning to achieve my goal( ~1.5 Million
>>>>>> requests/sec
>>>>>> >>> >>>>>> ).
>>>>>> >>> >>>>>>
>>>>>> >>> >>>>>> Server :
>>>>>> >>> >>>>>>
>>>>>> >>> >>>>>> Undertow server = Undertow.builder()
>>>>>> >>> >>>>>>                .addHttpListener(8009, "localhost")
>>>>>> >>> >>>>>>                .setHandler(new Handler()).build();
>>>>>> >>> >>>>>> server.start();
>>>>>> >>> >>>>>>
>>>>>> >>> >>>>>>
>>>>>> >>> >>>>>> Handler.Java
>>>>>> >>> >>>>>>
>>>>>> >>> >>>>>>     final Pooled<ByteBuffer> pooledByteBuffer =
>>>>>> >>> >>>>>>
>>>>>> >>> >>>>>> exchange.getConnection().getBufferPool().allocate();
>>>>>> >>> >>>>>> final ByteBuffer byteBuffer =
>>>>>> pooledByteBuffer.getResource();
>>>>>> >>> >>>>>>    byteBuffer.clear();
>>>>>> >>> >>>>>>    exchange.getRequestChannel().read(byteBuffer);
>>>>>> >>> >>>>>>    int pos = byteBuffer.position();
>>>>>> >>> >>>>>>    byteBuffer.rewind();
>>>>>> >>> >>>>>>    byte[] bytes = new byte[pos];
>>>>>> >>> >>>>>>    byteBuffer.get(bytes);
>>>>>> >>> >>>>>>    String requestBody = new String(bytes,
>>>>>> Charset.forName("UTF-8")
>>>>>> >>> >>>>>> );
>>>>>> >>> >>>>>>    byteBuffer.clear();
>>>>>> >>> >>>>>>    pooledByteBuffer.free();
>>>>>> >>> >>>>>>    final PostToKafka post2Kafka = new PostToKafka();
>>>>>> >>> >>>>>> try {
>>>>>> >>> >>>>>> post2Kafka.write2Kafka(requestBody);  { This API can
>>>>>> handle  ~2
>>>>>> >>> >>>>>> Millions events per sec }
>>>>>> >>> >>>>>> } catch (Exception e) {
>>>>>> >>> >>>>>> e.printStackTrace();
>>>>>> >>> >>>>>> }
>>>>>> >>> >>>>>>     exchange.getResponseHeaders()
>>>>>> .put(Headers.CONTENT_TYPE,
>>>>>> >>> >>>>>> "text/plain");
>>>>>> >>> >>>>>>     exchange.getResponseSender().send("SUCCESS");
>>>>>> >>> >>>>>>
>>>>>> >>> >>>>>>
>>>>>> >>> >>>>>> --Senthil
>>>>>> >>> >>>>>
>>>>>> >>> >>>>>
>>>>>> >>> >>>>>
>>>>>> >>> >>>>> _______________________________________________
>>>>>> >>> >>>>> 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
>>>>>>
>>>>>
>>>>>
>>>>
>>> _______________________________________________
>>> undertow-dev mailing list
>>> undertow-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>
>> --
>> Med venlig hilsen / Best regards
>>
>> *Kim Rasmussen*
>> Partner, IT Architect
>>
>> *Asseco Denmark A/S*
>> Kronprinsessegade 54
>> DK-1306 Copenhagen K
>> Mobile: +45 26 16 40 23 <+45%2026%2016%2040%2023>
>> Ph.: +45 33 36 46 60 <+45%2033%2036%2046%2060>
>> Fax: +45 33 36 46 61 <+45%2033%2036%2046%2061>
>>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170710/dc430c7d/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 31196 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20170710/dc430c7d/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 25115 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20170710/dc430c7d/attachment-0003.png 

From senthilec566 at gmail.com  Mon Jul 10 00:43:38 2017
From: senthilec566 at gmail.com (SenthilKumar K)
Date: Mon, 10 Jul 2017 10:13:38 +0530
Subject: [undertow-dev] Undertow Http Server - Handling 2 Millions
 Requests Per Second Per Instance
In-Reply-To: <CAD+L2cxNnuArSxSbyszSESwZfJi8Yf6Zj1JPCwEyO+4XaVUOYw@mail.gmail.com>
References: <CA+xmZH2ChvRWQGK4X-oFmzxdTzq7R2W7GPv0t=2VrkKDW2a6TQ@mail.gmail.com>
	<CA+xmZH1UDdugtkDvxTp9KdL_h2UtP7QRrz5As-KRj6M8W3DM1g@mail.gmail.com>
	<CALc5U3Fy1POagBsY39aMOtbFjJYRYN0SQs8cTu=jovxtxGx6DA@mail.gmail.com>
	<CA+xmZH3nLf_-JhdYGcbSpB4LzhkHSni3n+OTgj=J9WM=t1YQ6w@mail.gmail.com>
	<CALc5U3F_kYOiNsA9P28EyJM_utqm5LmmZiKusNLQQnobM0TLVg@mail.gmail.com>
	<CA+xmZH3fOcO3L6ztGiqty33jeeXeJjmjGKVqBCXzB3NdkpA2Pg@mail.gmail.com>
	<CAD+L2cw-KCPNCy-+fYheUMTMmj-7+GdAi9y568HcTWKoBX5aOg@mail.gmail.com>
	<CALc5U3HdmPTSeePwft-zc2hRELvim8Rpbr05QYaR-6prpGUo4A@mail.gmail.com>
	<CA+xmZH0OTSpTYhvk94Xt2B66-BaAFKWNNp7YbBbj4+ZQ6ZB9GQ@mail.gmail.com>
	<CAD+L2cy-w8xsu5q2y7vTQzFSy_9V9Jm1X=EaALV6QYp3dVS++A@mail.gmail.com>
	<CANd+gFx4WLY54cPirYOc6PiRByY01HAKLVX0XiEEFOBmae5zxg@mail.gmail.com>
	<CA+xmZH12c=meg-wv982jAF-tX_5etmq66LVa0VOkB3HhM_ZL-g@mail.gmail.com>
	<CA+xmZH2p09d_8Pn+Nsje2sndCbwuj8e7FN95Bq78p+JYUZfWKg@mail.gmail.com>
	<CAGX6Y=1vJR_gZ_PzutBPo7+LcrXwdJF+fdhzpfOfg0FTe9Ugrg@mail.gmail.com>
	<CA+xmZH1dvBrEft3ERNe6kpVGgO=R2D0ciqjwKLjQ_GcXhMFrWA@mail.gmail.com>
	<CAD+L2cwuxju5Q0e0NG+Soaxz6evfALsN-KLvw-1haTucPL4XtQ@mail.gmail.com>
	<CAD+L2cxNnuArSxSbyszSESwZfJi8Yf6Zj1JPCwEyO+4XaVUOYw@mail.gmail.com>
Message-ID: <CA+xmZH0rtoEPXLmK=10wE72TSK3a3oV3oqNdBvENg5hYNJnjcQ@mail.gmail.com>

Hi Douglas ,   Here is the code for Undertow
https://github.com/senthilec566/undertow and Netty
https://github.com/senthilec566/microHttp . Both tested in default
settings..

Both Undertow and Netty respond SUCCESS or FAILURE.

I'd love to optimize undertow code and rerun the test case if required...

Another test result:

Undertow:
./wrk -c 10000 -d 10m -t 300 -s scripts/post_data.lua -R 500000
http://undertow:8009/
Running 10m test @ http://undertow:8009/
  300 threads and 10000 connections
Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     3.70m     2.07m    7.40m    57.73%
    Req/Sec   449.71      6.45   474.00     74.93%
  80640669 requests in 10.00m, 9.91GB read
  Socket errors: connect 0, read 353, write 0, timeout 448
Requests/sec: *134457*.31
Transfer/sec:     16.93MB

Netty:
./wrk -c 10000 -d 10m -t 300 -s scripts/post_data.lua -R 500000
http://netty:8009/
Running 10m test @ http://netty:8009/
  300 threads and 10000 connections
Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     2.76m     1.54m    5.70m    57.83%
    Req/Sec   763.90     73.21     1.12k    69.15%
  137216075 requests in 10.00m, 12.14GB read
  Socket errors: connect 0, read 0, write 0, timeout 42
Requests/sec: *228796*.63
Transfer/sec:     20.73MB


--Senthil

On Mon, Jul 10, 2017 at 3:12 AM, Stuart Douglas <sdouglas at redhat.com> wrote:

> Also it looks like you are sending more data in the undertow response.
> Mb/s is very similar, while req/sec is lower.
>
> Stuart
>
> On 10 Jul. 2017 9:39 am, "Stuart Douglas" <sdouglas at redhat.com> wrote:
>
>> Are they both using the same number of threads? Also what are you doing
>> in the handler? Are you calling dispatch? Dispatch is relativity slow in
>> these micro benchmarks, as it dispatches to a thread pool.
>>
>> Stuart
>>
>> On 9 Jul. 2017 4:34 am, "SenthilKumar K" <senthilec566 at gmail.com> wrote:
>>
>> Yet to try that .. My testcase  did not cover tuning no of threads .. but
>> even if we try to increase number of threads I believe both framework
>> performance would improve !! Different thoughts ??
>>
>> Anyway I like to add another test case by changing threads !!
>>
>> --Senthil
>>
>> On Jul 8, 2017 9:38 PM, "Kim Rasmussen" <kr at asseco.dk> wrote:
>>
>>> Have you tried playing around with the number of io and worker threads?
>>>
>>> l?r. 8. jul. 2017 kl. 17.28 skrev SenthilKumar K <senthilec566 at gmail.com
>>> >:
>>>
>>>> Any comments on *Undertow Vs Netty* ? Am i doing wrong benchmark
>>>> testing  ?? Should i change benchmark strategy ?
>>>>
>>>> --Senthil
>>>>
>>>> On Fri, Jul 7, 2017 at 3:14 PM, SenthilKumar K <senthilec566 at gmail.com>
>>>> wrote:
>>>>
>>>>> Sorry for delay in responding to this thread!
>>>>>
>>>>> Thanks to everyone who helped me to Optimize Undertow Server.
>>>>>
>>>>> Here is the comparison after benchmarking my use case against Netty:
>>>>>
>>>>> *Undertow Vs Netty :*
>>>>>
>>>>> Test Case 1 :
>>>>> Simple Request Response ( No Kafka ):
>>>>>
>>>>> *Undertow:*
>>>>> Running 10m test @ http://198.18.134.13:8009/
>>>>>   500 threads and 5000 connections
>>>>>   Thread Stats   Avg      Stdev     Max   +/- Stdev
>>>>>     Latency     *3.52m *    2.64m    8.96m    54.63%
>>>>>     Req/Sec   376.58    103.18     0.99k    80.53%
>>>>>   111628942 requests in 10.00m, 13.72GB read
>>>>>   Socket errors: connect 0, read 28, write 0, timeout 2
>>>>> Requests/sec: *186122.56*
>>>>> Transfer/sec:     23.43MB
>>>>>
>>>>> *Netty:*
>>>>> Running 10m test @ http://198.18.134.13:8009/
>>>>> 500 threads and 5000 connections
>>>>> Thread Stats   Avg      Stdev     Max   +/- Stdev
>>>>>     Latency     *3.77m*     2.10m    7.51m    57.73%
>>>>>     Req/Sec   518.63     31.78   652.00     70.25%
>>>>>   155406992 requests in 10.00m, 13.82GB read
>>>>>   Socket errors: connect 0, read 49, write 0, timeout 0
>>>>> Requests/sec: *259107*.30
>>>>> Transfer/sec:     24.17MB
>>>>>
>>>>>
>>>>> *Test Case 2:*
>>>>> Request --> Read --> Send it Kafka :
>>>>>
>>>>> *Undertow:*
>>>>> Running 10m test @ http://198.18.134.13:8009/
>>>>> 500 threads and 5000 connections
>>>>> Thread Stats   Avg      Stdev     Max   +/- Stdev
>>>>>     Latency     *4.37m *    2.46m    8.72m    57.83%
>>>>>     Req/Sec   267.32      5.17   287.00     74.52%
>>>>>   80044045 requests in 10.00m, 9.84GB read
>>>>>   Socket errors: connect 0, read 121, write 0, timeout 0
>>>>> Requests/sec: *133459.79*
>>>>> Transfer/sec:     16.80MB
>>>>>
>>>>> *Netty:*
>>>>> Running 10m test @ http://198.18.134.13:8009/
>>>>> 500 threads and 5000 connections
>>>>> Thread Stats   Avg      Stdev     Max   +/- Stdev
>>>>>     Latency     *3.78m *    2.10m    7.55m    57.79%
>>>>>     Req/Sec   516.92     28.84   642.00     69.60%
>>>>>   154770536 requests in 10.00m, 13.69GB read
>>>>>   Socket errors: connect 0, read 11, write 0, timeout 101
>>>>> Requests/sec: *258049.39*
>>>>> Transfer/sec:     23.38MB
>>>>>
>>>>>
>>>>>
>>>>> CPU Usage:
>>>>> *Undertow:*
>>>>> [image: Inline image 1]
>>>>>
>>>>> *Netty:*
>>>>> [image: Inline image 2]
>>>>>
>>>>>
>>>>> --Senthil
>>>>>
>>>>> On Thu, Jun 29, 2017 at 7:34 AM, Bill O'Neil <bill at dartalley.com>
>>>>> wrote:
>>>>>
>>>>>> 1. Can you run the benchmark with the kafka line commented out at
>>>>>> first and then again with it not commented out?
>>>>>> 2. What rates were you getting with Jetty and Netty?
>>>>>> 3. Are you running the tests from the same machine or a different
>>>>>> one? If its the same machine and its using 20 threads they will be
>>>>>> contending with undertows IO threads.
>>>>>> 4. You can probably ignore the POST check if thats all your going to
>>>>>> accept and its not a public api.
>>>>>>
>>>>>> import io.undertow.server.HttpHandler;
>>>>>> import io.undertow.server.HttpServerExchange;
>>>>>> import io.undertow.util.Headers;
>>>>>> import io.undertow.util.Methods;
>>>>>>
>>>>>> public class DLRHandler implements HttpHandler {
>>>>>>
>>>>>>     final public static String _SUCCESS="SUCCESS";
>>>>>>     final public static String _FAILURE="FAILURE";
>>>>>>     final PostToKafka post2Kafka = new PostToKafka();
>>>>>>
>>>>>>     @Override
>>>>>>     public void handleRequest( final HttpServerExchange exchange)
>>>>>> throws Exception {
>>>>>>         if (exchange.getRequestMethod().equals(Methods.POST)) {
>>>>>>               exchange.getRequestReceiver().receiveFullString((
>>>>>> exchangeReq, data) -> {
>>>>>>                   //post2Kafka.write2Kafka(data); // write it to
>>>>>> Kafka
>>>>>>                   exchangeReq.getResponseHeaders().put(Headers.CONTENT_TYPE,
>>>>>> "text/plain");
>>>>>>                   exchangeReq.getResponseSender().send(_SUCCESS);
>>>>>>               },
>>>>>>              (exchangeReq, exception) -> {
>>>>>>                  exchangeReq.getResponseHeaders().put(Headers.CONTENT_TYPE,
>>>>>> "text/plain");
>>>>>>                  exchangeReq.getResponseSender().send(_FAILURE);
>>>>>>             });
>>>>>>          }else{
>>>>>>              throw new Exception("Method GET not supported by Server
>>>>>> ");
>>>>>>          }
>>>>>>     }
>>>>>> }
>>>>>>
>>>>>> On Wed, Jun 28, 2017 at 6:59 PM, Stuart Douglas <sdouglas at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> The multiple dispatches() are unnecessary (well the second one to the
>>>>>>> IO thread is definitely unnecessary, the first one is only required
>>>>>>> if
>>>>>>> post2Kafka.write2Kafka(data); is a blocking operation and needs to be
>>>>>>> executed in a worker thread).
>>>>>>>
>>>>>>> Stuart
>>>>>>>
>>>>>>> On Wed, Jun 28, 2017 at 5:42 PM, SenthilKumar K <
>>>>>>> senthilec566 at gmail.com> wrote:
>>>>>>> > After modifying the code below i  could see the improvement ( not
>>>>>>> much
>>>>>>> > slightly ) in server - 65k req/sec.
>>>>>>> >
>>>>>>> > import io.undertow.server.HttpHandler;
>>>>>>> > import io.undertow.server.HttpServerExchange;
>>>>>>> > import io.undertow.util.Headers;
>>>>>>> > import io.undertow.util.Methods;
>>>>>>> >
>>>>>>> > public class DLRHandler implements HttpHandler {
>>>>>>> >
>>>>>>> >     final public static String _SUCCESS="SUCCESS";
>>>>>>> >     final public static String _FAILURE="FAILURE";
>>>>>>> >     final PostToKafka post2Kafka = new PostToKafka();
>>>>>>> >
>>>>>>> >     @Override
>>>>>>> >     public void handleRequest( final HttpServerExchange exchange)
>>>>>>> throws
>>>>>>> > Exception {
>>>>>>> >         if (exchange.getRequestMethod().equals(Methods.POST)) {
>>>>>>> >                 exchange.getRequestReceiver().receiveFullString((
>>>>>>> > exchangeReq, data) -> {
>>>>>>> >                   exchangeReq.dispatch(() -> {
>>>>>>> >                       post2Kafka.write2Kafka(data); // write it to
>>>>>>> Kafka
>>>>>>> >                       exchangeReq.dispatch(exchangeReq.getIoThread(),
>>>>>>> () ->
>>>>>>> > {
>>>>>>> >
>>>>>>> > exchangeReq.getResponseHeaders().put(Headers.CONTENT_TYPE,
>>>>>>> "text/plain");
>>>>>>> >                           exchangeReq.getResponseSender
>>>>>>> ().send(_SUCCESS);
>>>>>>> >                       });
>>>>>>> >                   });
>>>>>>> >               },
>>>>>>> >              (exchangeReq, exception) -> {
>>>>>>> >                  exchangeReq.getResponseHeaders
>>>>>>> ().put(Headers.CONTENT_TYPE,
>>>>>>> > "text/plain");
>>>>>>> >                  exchangeReq.getResponseSender().send(_FAILURE);
>>>>>>> >             });
>>>>>>> >          }else{
>>>>>>> >              throw new Exception("Method GET not supported by
>>>>>>> Server ");
>>>>>>> >          }
>>>>>>> >     }
>>>>>>> > }
>>>>>>> >
>>>>>>> >
>>>>>>> > Pls review this and let me know if i'm doing anything wrong here
>>>>>>> ...
>>>>>>> > --Senthil
>>>>>>> >
>>>>>>> > On Fri, Jun 23, 2017 at 1:30 PM, Antoine Girard <
>>>>>>> antoine.girard at ymail.com>
>>>>>>> > wrote:
>>>>>>> >>
>>>>>>> >> Also, to come back on the JVM warmup, this will give you enough
>>>>>>> answers:
>>>>>>> >>
>>>>>>> >> https://stackoverflow.com/questions/36198278/why-does-the-jv
>>>>>>> m-require-warmup
>>>>>>> >>
>>>>>>> >> For your, it means that you have to run your tests for a few
>>>>>>> minutes
>>>>>>> >> before starting your actual measurements.
>>>>>>> >>
>>>>>>> >> I am also interested about how Netty / Jetty perform under the
>>>>>>> same
>>>>>>> >> conditions, please post!
>>>>>>> >>
>>>>>>> >> Cheers,
>>>>>>> >> Antoine
>>>>>>> >>
>>>>>>> >> On Fri, Jun 23, 2017 at 1:24 AM, Stuart Douglas <
>>>>>>> sdouglas at redhat.com>
>>>>>>> >> wrote:
>>>>>>> >>>
>>>>>>> >>> Are you actually testing with the 'System.out.println(" Received
>>>>>>> >>> String ==> "+message);'. System.out is incredibly slow.
>>>>>>> >>>
>>>>>>> >>> Stuart
>>>>>>> >>>
>>>>>>> >>> On Fri, Jun 23, 2017 at 7:01 AM, SenthilKumar K <
>>>>>>> senthilec566 at gmail.com>
>>>>>>> >>> wrote:
>>>>>>> >>> > Sorry , I'm not an expert in JVM .. How do we do Warm Up JVM ?
>>>>>>> >>> >
>>>>>>> >>> > Here is the JVM args to Server:
>>>>>>> >>> >
>>>>>>> >>> > nohup java -Xmx4g -Xms4g -XX:MetaspaceSize=96m -XX:+UseG1GC
>>>>>>> >>> > -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35
>>>>>>> >>> > -XX:G1HeapRegionSize=16M -XX:MinMetaspaceFreeRatio=50
>>>>>>> >>> > -XX:MaxMetaspaceFreeRatio=80 -cp undertow-0.0.1.jar
>>>>>>> HelloWorldServer
>>>>>>> >>> >
>>>>>>> >>> >
>>>>>>> >>> > --Senthil
>>>>>>> >>> >
>>>>>>> >>> >
>>>>>>> >>> > On Fri, Jun 23, 2017 at 2:23 AM, Antoine Girard
>>>>>>> >>> > <antoine.girard at ymail.com>
>>>>>>> >>> > wrote:
>>>>>>> >>> >>
>>>>>>> >>> >> Do you warm up your jvm prior to the testing?
>>>>>>> >>> >>
>>>>>>> >>> >> Cheers,
>>>>>>> >>> >> Antoine
>>>>>>> >>> >>
>>>>>>> >>> >> On Thu, Jun 22, 2017 at 10:42 PM, SenthilKumar K
>>>>>>> >>> >> <senthilec566 at gmail.com>
>>>>>>> >>> >> wrote:
>>>>>>> >>> >>>
>>>>>>> >>> >>> Thanks Bill n Antoine ..
>>>>>>> >>> >>>
>>>>>>> >>> >>>
>>>>>>> >>> >>> Here is the updated one : ( tried without Kafka API ) .
>>>>>>> >>> >>>
>>>>>>> >>> >>> public class HelloWorldServer {
>>>>>>> >>> >>>
>>>>>>> >>> >>> public static void main(final String[] args) {
>>>>>>> >>> >>> Undertow server = Undertow.builder().addHttpListener(8009,
>>>>>>> >>> >>> "localhost").setHandler(new HttpHandler() {
>>>>>>> >>> >>> @Override
>>>>>>> >>> >>> public void handleRequest(final HttpServerExchange exchange)
>>>>>>> throws
>>>>>>> >>> >>> Exception {
>>>>>>> >>> >>> if (exchange.getRequestMethod().equals(Methods.POST)) {
>>>>>>> >>> >>> exchange.getRequestReceiver().receiveFullString(new
>>>>>>> >>> >>> Receiver.FullStringCallback() {
>>>>>>> >>> >>>                    @Override
>>>>>>> >>> >>>                    public void handle(HttpServerExchange
>>>>>>> exchange,
>>>>>>> >>> >>> String
>>>>>>> >>> >>> message) {
>>>>>>> >>> >>>                     System.out.println(" Received String ==>
>>>>>>> >>> >>> "+message);
>>>>>>> >>> >>>                        exchange.getResponseSender().s
>>>>>>> end(message);
>>>>>>> >>> >>>                    }
>>>>>>> >>> >>>                });
>>>>>>> >>> >>> } else {
>>>>>>> >>> >>> exchange.getResponseHeaders().put(Headers.CONTENT_TYPE,
>>>>>>> >>> >>> "text/plain");
>>>>>>> >>> >>> exchange.getResponseSender().send("FAILURE");
>>>>>>> >>> >>> }
>>>>>>> >>> >>> }
>>>>>>> >>> >>> }).build();
>>>>>>> >>> >>> server.start();
>>>>>>> >>> >>> }
>>>>>>> >>> >>> }
>>>>>>> >>> >>>
>>>>>>> >>> >>>
>>>>>>> >>> >>> Oops seems to no improvement :
>>>>>>> >>> >>>
>>>>>>> >>> >>> Running 1m test @ http://localhost:8009/
>>>>>>> >>> >>>   100 threads and 1000 connections
>>>>>>> >>> >>>   Thread Stats   Avg      Stdev     Max   +/- Stdev
>>>>>>> >>> >>>     Latency    25.79ms   22.18ms 289.48ms   67.66%
>>>>>>> >>> >>>     Req/Sec   437.76     61.71     2.30k    80.26%
>>>>>>> >>> >>>   Latency Distribution
>>>>>>> >>> >>>      50%   22.60ms
>>>>>>> >>> >>>      75%   37.83ms
>>>>>>> >>> >>>      90%   55.32ms
>>>>>>> >>> >>>      99%   90.47ms
>>>>>>> >>> >>>   2625607 requests in 1.00m, 2.76GB read
>>>>>>> >>> >>> Requests/sec:  43688.42
>>>>>>> >>> >>> Transfer/sec:     47.08MB
>>>>>>> >>> >>>
>>>>>>> >>> >>>
>>>>>>> >>> >>> :-( :-( ..
>>>>>>> >>> >>>
>>>>>>> >>> >>>
>>>>>>> >>> >>> --Senthil
>>>>>>> >>> >>>
>>>>>>> >>> >>>
>>>>>>> >>> >>> On Fri, Jun 23, 2017 at 1:47 AM, Antoine Girard
>>>>>>> >>> >>> <antoine.girard at ymail.com> wrote:
>>>>>>> >>> >>>>
>>>>>>> >>> >>>> You can use the Receiver API, specifically for that purpose.
>>>>>>> >>> >>>> On the exchange, call: getRequestReceiver();
>>>>>>> >>> >>>>
>>>>>>> >>> >>>> You will get a receiver object:
>>>>>>> >>> >>>>
>>>>>>> >>> >>>>
>>>>>>> >>> >>>> https://github.com/undertow-io
>>>>>>> /undertow/blob/master/core/src/main/java/io/undertow/io/Rece
>>>>>>> iver.java
>>>>>>> >>> >>>>
>>>>>>> >>> >>>> On the receiver you can call: receiveFullString, you have
>>>>>>> to pass it
>>>>>>> >>> >>>> a
>>>>>>> >>> >>>> callback that will be called when the whole body has been
>>>>>>> read.
>>>>>>> >>> >>>>
>>>>>>> >>> >>>> Please share your results when you test this further!
>>>>>>> >>> >>>>
>>>>>>> >>> >>>> Cheers,
>>>>>>> >>> >>>> Antoine
>>>>>>> >>> >>>>
>>>>>>> >>> >>>>
>>>>>>> >>> >>>> On Thu, Jun 22, 2017 at 8:27 PM, SenthilKumar K
>>>>>>> >>> >>>> <senthilec566 at gmail.com>
>>>>>>> >>> >>>> wrote:
>>>>>>> >>> >>>>>
>>>>>>> >>> >>>>> Seems to Reading Request body is wrong , So what is the
>>>>>>> efficient
>>>>>>> >>> >>>>> way
>>>>>>> >>> >>>>> of reading request body in undertow ?
>>>>>>> >>> >>>>>
>>>>>>> >>> >>>>> --Senthil
>>>>>>> >>> >>>>>
>>>>>>> >>> >>>>> On Thu, Jun 22, 2017 at 11:30 PM, SenthilKumar K
>>>>>>> >>> >>>>> <senthilec566 at gmail.com> wrote:
>>>>>>> >>> >>>>>>
>>>>>>> >>> >>>>>> Hello Undertow Dev Team ,
>>>>>>> >>> >>>>>>
>>>>>>> >>> >>>>>>       I have been working on the use case where i should
>>>>>>> create
>>>>>>> >>> >>>>>> simple
>>>>>>> >>> >>>>>> http server to serve 1.5 Million Requests per Second per
>>>>>>> Instance
>>>>>>> >>> >>>>>> ..
>>>>>>> >>> >>>>>>
>>>>>>> >>> >>>>>>
>>>>>>> >>> >>>>>> Here is the benchmark result of Undertow :
>>>>>>> >>> >>>>>>
>>>>>>> >>> >>>>>> Running 1m test @ http://127.0.0.1:8009/
>>>>>>> >>> >>>>>>   20 threads and 40 connections
>>>>>>> >>> >>>>>>   Thread Stats   Avg      Stdev     Max   +/- Stdev
>>>>>>> >>> >>>>>>     Latency     2.51ms   10.75ms 282.22ms   99.28%
>>>>>>> >>> >>>>>>     Req/Sec     1.12k   316.65     1.96k    54.50%
>>>>>>> >>> >>>>>>   Latency Distribution
>>>>>>> >>> >>>>>>      50%    1.43ms
>>>>>>> >>> >>>>>>      75%    2.38ms
>>>>>>> >>> >>>>>>      90%    2.90ms
>>>>>>> >>> >>>>>>      99%   10.45ms
>>>>>>> >>> >>>>>>   1328133 requests in 1.00m, 167.19MB read
>>>>>>> >>> >>>>>> Requests/sec:  22127.92
>>>>>>> >>> >>>>>> Transfer/sec:      2.79MB
>>>>>>> >>> >>>>>>
>>>>>>> >>> >>>>>> This is less compared to other frameworks like Jetty and
>>>>>>> Netty ..
>>>>>>> >>> >>>>>> But
>>>>>>> >>> >>>>>> originally Undertow is high performant http server ..
>>>>>>> >>> >>>>>>
>>>>>>> >>> >>>>>> Hardware details:
>>>>>>> >>> >>>>>> Xeon CPU E3-1270 v5 machine with 4 cores ( Clock 100 MHz,
>>>>>>> Capacity
>>>>>>> >>> >>>>>> 4
>>>>>>> >>> >>>>>> GHz) , Memory : 32 G , Available memory 31 G.
>>>>>>> >>> >>>>>>
>>>>>>> >>> >>>>>> I would need Undertow experts to review the server code
>>>>>>> below and
>>>>>>> >>> >>>>>> advice me on tuning to achieve my goal( ~1.5 Million
>>>>>>> requests/sec
>>>>>>> >>> >>>>>> ).
>>>>>>> >>> >>>>>>
>>>>>>> >>> >>>>>> Server :
>>>>>>> >>> >>>>>>
>>>>>>> >>> >>>>>> Undertow server = Undertow.builder()
>>>>>>> >>> >>>>>>                .addHttpListener(8009, "localhost")
>>>>>>> >>> >>>>>>                .setHandler(new Handler()).build();
>>>>>>> >>> >>>>>> server.start();
>>>>>>> >>> >>>>>>
>>>>>>> >>> >>>>>>
>>>>>>> >>> >>>>>> Handler.Java
>>>>>>> >>> >>>>>>
>>>>>>> >>> >>>>>>     final Pooled<ByteBuffer> pooledByteBuffer =
>>>>>>> >>> >>>>>>
>>>>>>> >>> >>>>>> exchange.getConnection().getBufferPool().allocate();
>>>>>>> >>> >>>>>> final ByteBuffer byteBuffer =
>>>>>>> pooledByteBuffer.getResource();
>>>>>>> >>> >>>>>>    byteBuffer.clear();
>>>>>>> >>> >>>>>>    exchange.getRequestChannel().read(byteBuffer);
>>>>>>> >>> >>>>>>    int pos = byteBuffer.position();
>>>>>>> >>> >>>>>>    byteBuffer.rewind();
>>>>>>> >>> >>>>>>    byte[] bytes = new byte[pos];
>>>>>>> >>> >>>>>>    byteBuffer.get(bytes);
>>>>>>> >>> >>>>>>    String requestBody = new String(bytes,
>>>>>>> Charset.forName("UTF-8")
>>>>>>> >>> >>>>>> );
>>>>>>> >>> >>>>>>    byteBuffer.clear();
>>>>>>> >>> >>>>>>    pooledByteBuffer.free();
>>>>>>> >>> >>>>>>    final PostToKafka post2Kafka = new PostToKafka();
>>>>>>> >>> >>>>>> try {
>>>>>>> >>> >>>>>> post2Kafka.write2Kafka(requestBody);  { This API can
>>>>>>> handle  ~2
>>>>>>> >>> >>>>>> Millions events per sec }
>>>>>>> >>> >>>>>> } catch (Exception e) {
>>>>>>> >>> >>>>>> e.printStackTrace();
>>>>>>> >>> >>>>>> }
>>>>>>> >>> >>>>>>     exchange.getResponseHeaders()
>>>>>>> .put(Headers.CONTENT_TYPE,
>>>>>>> >>> >>>>>> "text/plain");
>>>>>>> >>> >>>>>>     exchange.getResponseSender().send("SUCCESS");
>>>>>>> >>> >>>>>>
>>>>>>> >>> >>>>>>
>>>>>>> >>> >>>>>> --Senthil
>>>>>>> >>> >>>>>
>>>>>>> >>> >>>>>
>>>>>>> >>> >>>>>
>>>>>>> >>> >>>>> _______________________________________________
>>>>>>> >>> >>>>> 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
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>> _______________________________________________
>>>> undertow-dev mailing list
>>>> undertow-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>
>>> --
>>> Med venlig hilsen / Best regards
>>>
>>> *Kim Rasmussen*
>>> Partner, IT Architect
>>>
>>> *Asseco Denmark A/S*
>>> Kronprinsessegade 54
>>> DK-1306 Copenhagen K
>>> Mobile: +45 26 16 40 23 <+45%2026%2016%2040%2023>
>>> Ph.: +45 33 36 46 60 <+45%2033%2036%2046%2060>
>>> Fax: +45 33 36 46 61 <+45%2033%2036%2046%2061>
>>>
>>
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170710/fab565c3/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 25115 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20170710/fab565c3/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 31196 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20170710/fab565c3/attachment-0003.png 

From eldadru at gmail.com  Mon Jul 10 05:31:00 2017
From: eldadru at gmail.com (Eldad Rudich)
Date: Mon, 10 Jul 2017 12:31:00 +0300
Subject: [undertow-dev] Best practice for receiving/writing HTTP body by
	chunks
Message-ID: <CAG-POd2mEEGFyP1wu6HvsPCbcXTfvM=g8Q32dxUXdB2LEZnTOQ@mail.gmail.com>

Hi,

I'm implementing custom HTTP reverse proxy using Undertow.
My server is listening to requests and when a new request arrives, It wraps
the request in a proprietary protocol and redirect to another component in
my system.
That component takes the request data, unpack it, send it to the actual web
server, get's the response and send the response back to my Undertow server
in the same proprietary protocol.
The server unpacks the response and writes it back to the user's browser.

All works very well for "small" requests/response but for request/response
that has body data that exceed some predefined amount I would like to split
the request/response to chunks ( my own chunking mechanism, not related to
HTTP chunking) to better handle such scenarios and not hold the entire data
in the server's memory.

In order to do that I need access to the request/response body bytes,
I came by this thread:
http://lists.jboss.org/pipermail/undertow-dev/2015-January/001080.html and
tried to implement both proposed solutions

When I used the async interface:

HttpServerExchange.getResponseSender().send(bodyByteBuffer, myIoCallback)

Sometimes my callback just not called ( nor the onComplete or the
onException callbacks) for unknown reasons.

So I tried the blocking interface instead ( from dispatched handler ):

HttpServerExchange.startBlocking()

HttpServerExchange.getResponseSender().send(bodyByteBuffer)

That works but I read somewhere in this mailing list that the async
interface is more efficient.

The same behavior occurred when trying to receive the request body using:
HttpServerExchange.getRequestReceiver()
and also solved using the blocking interface.

Am I missing something? what are the best practices for reading/writing
partial request/response body?

Best,
Eldad.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170710/f085163e/attachment.html 

From sdouglas at redhat.com  Wed Jul 12 18:57:39 2017
From: sdouglas at redhat.com (Stuart Douglas)
Date: Thu, 13 Jul 2017 10:57:39 +1200
Subject: [undertow-dev] Undertow Http Server - Handling 2 Millions
 Requests Per Second Per Instance
In-Reply-To: <CA+xmZH0rtoEPXLmK=10wE72TSK3a3oV3oqNdBvENg5hYNJnjcQ@mail.gmail.com>
References: <CA+xmZH2ChvRWQGK4X-oFmzxdTzq7R2W7GPv0t=2VrkKDW2a6TQ@mail.gmail.com>
	<CA+xmZH1UDdugtkDvxTp9KdL_h2UtP7QRrz5As-KRj6M8W3DM1g@mail.gmail.com>
	<CALc5U3Fy1POagBsY39aMOtbFjJYRYN0SQs8cTu=jovxtxGx6DA@mail.gmail.com>
	<CA+xmZH3nLf_-JhdYGcbSpB4LzhkHSni3n+OTgj=J9WM=t1YQ6w@mail.gmail.com>
	<CALc5U3F_kYOiNsA9P28EyJM_utqm5LmmZiKusNLQQnobM0TLVg@mail.gmail.com>
	<CA+xmZH3fOcO3L6ztGiqty33jeeXeJjmjGKVqBCXzB3NdkpA2Pg@mail.gmail.com>
	<CAD+L2cw-KCPNCy-+fYheUMTMmj-7+GdAi9y568HcTWKoBX5aOg@mail.gmail.com>
	<CALc5U3HdmPTSeePwft-zc2hRELvim8Rpbr05QYaR-6prpGUo4A@mail.gmail.com>
	<CA+xmZH0OTSpTYhvk94Xt2B66-BaAFKWNNp7YbBbj4+ZQ6ZB9GQ@mail.gmail.com>
	<CAD+L2cy-w8xsu5q2y7vTQzFSy_9V9Jm1X=EaALV6QYp3dVS++A@mail.gmail.com>
	<CANd+gFx4WLY54cPirYOc6PiRByY01HAKLVX0XiEEFOBmae5zxg@mail.gmail.com>
	<CA+xmZH12c=meg-wv982jAF-tX_5etmq66LVa0VOkB3HhM_ZL-g@mail.gmail.com>
	<CA+xmZH2p09d_8Pn+Nsje2sndCbwuj8e7FN95Bq78p+JYUZfWKg@mail.gmail.com>
	<CAGX6Y=1vJR_gZ_PzutBPo7+LcrXwdJF+fdhzpfOfg0FTe9Ugrg@mail.gmail.com>
	<CA+xmZH1dvBrEft3ERNe6kpVGgO=R2D0ciqjwKLjQ_GcXhMFrWA@mail.gmail.com>
	<CAD+L2cwuxju5Q0e0NG+Soaxz6evfALsN-KLvw-1haTucPL4XtQ@mail.gmail.com>
	<CAD+L2cxNnuArSxSbyszSESwZfJi8Yf6Zj1JPCwEyO+4XaVUOYw@mail.gmail.com>
	<CA+xmZH0rtoEPXLmK=10wE72TSK3a3oV3oqNdBvENg5hYNJnjcQ@mail.gmail.com>
Message-ID: <CAD+L2cwDzU_KURUXxuaj2PVbBZvn7gEe1ax+yQSwE1PMdoBxdQ@mail.gmail.com>

If the kafka code is truly non-blocking then you should not be calling
dispatch() at all in the Undertow code. Thread pool dispatch is very
expensive compared to other operations.

In terms of the response size you might want to
set io.undertow.UndertowOptions#ALWAYS_SET_KEEP_ALIVE to false. By default
undertow will send a Connection: keep-alive header, which can inflate the
response size on these sort of micro benchmarks. It is generally a good
idea to use telnet to connect to both servers and see exactly what the
response is, so you can be sure the response size is the same and you are
doing an accurate comparison (ALWAYS_SET_DATE is another one you may want
to set to false).

In terms of number of threads AFAIK Netty and Undertow have different
thread pool sizes, and the 'ideal' size is very hard to pick by default, as
it depends on a lot of factors. In practice the only way to figure out the
ideal size is by trial and error (more threads does not necessarily mean
faster).

There are also other factors that can affect micro benchmarks like this
that do not affect real world performance. e.g. one that we have had
problems with in the path is IO thread 'clumping', where because all the
benchmark connections are created at the some time one IO thread can end up
with more than its fair share of connections to service. In the real world
this is not a problem, as connections come and go and busier threads will
tend to accept less connections, but to deal with the micro benchmark issue
we now allocate connections to IO threads based on a hash of the TCP
connection metadata. You have to be very very careful in how you design
these sort of benchmarks, as they are very sensitive to even minor changes.

Another thing I will point out is that unless you have some very big
hardware you are unlikely to get 2million requests/sec without using HTTP
pipelining, the underlying network hardware/OS will probably not be able to
perform that many read/write operations per second.

Stuart



On Mon, Jul 10, 2017 at 4:43 PM, SenthilKumar K <senthilec566 at gmail.com>
wrote:

> Hi Douglas ,   Here is the code for Undertow https://github.com/
> senthilec566/undertow and Netty https://github.com/senthilec566/microHttp
> . Both tested in default settings..
>
> Both Undertow and Netty respond SUCCESS or FAILURE.
>
> I'd love to optimize undertow code and rerun the test case if required...
>
> Another test result:
>
> Undertow:
> ./wrk -c 10000 -d 10m -t 300 -s scripts/post_data.lua -R 500000
> http://undertow:8009/
> Running 10m test @ http://undertow:8009/
>   300 threads and 10000 connections
> Thread Stats   Avg      Stdev     Max   +/- Stdev
>     Latency     3.70m     2.07m    7.40m    57.73%
>     Req/Sec   449.71      6.45   474.00     74.93%
>   80640669 requests in 10.00m, 9.91GB read
>   Socket errors: connect 0, read 353, write 0, timeout 448
> Requests/sec: *134457*.31
> Transfer/sec:     16.93MB
>
> Netty:
> ./wrk -c 10000 -d 10m -t 300 -s scripts/post_data.lua -R 500000
> http://netty:8009/
> Running 10m test @ http://netty:8009/
>   300 threads and 10000 connections
> Thread Stats   Avg      Stdev     Max   +/- Stdev
>     Latency     2.76m     1.54m    5.70m    57.83%
>     Req/Sec   763.90     73.21     1.12k    69.15%
>   137216075 requests in 10.00m, 12.14GB read
>   Socket errors: connect 0, read 0, write 0, timeout 42
> Requests/sec: *228796*.63
> Transfer/sec:     20.73MB
>
>
> --Senthil
>
> On Mon, Jul 10, 2017 at 3:12 AM, Stuart Douglas <sdouglas at redhat.com>
> wrote:
>
>> Also it looks like you are sending more data in the undertow response.
>> Mb/s is very similar, while req/sec is lower.
>>
>> Stuart
>>
>> On 10 Jul. 2017 9:39 am, "Stuart Douglas" <sdouglas at redhat.com> wrote:
>>
>>> Are they both using the same number of threads? Also what are you doing
>>> in the handler? Are you calling dispatch? Dispatch is relativity slow in
>>> these micro benchmarks, as it dispatches to a thread pool.
>>>
>>> Stuart
>>>
>>> On 9 Jul. 2017 4:34 am, "SenthilKumar K" <senthilec566 at gmail.com> wrote:
>>>
>>> Yet to try that .. My testcase  did not cover tuning no of threads ..
>>> but even if we try to increase number of threads I believe both framework
>>> performance would improve !! Different thoughts ??
>>>
>>> Anyway I like to add another test case by changing threads !!
>>>
>>> --Senthil
>>>
>>> On Jul 8, 2017 9:38 PM, "Kim Rasmussen" <kr at asseco.dk> wrote:
>>>
>>>> Have you tried playing around with the number of io and worker threads?
>>>>
>>>> l?r. 8. jul. 2017 kl. 17.28 skrev SenthilKumar K <
>>>> senthilec566 at gmail.com>:
>>>>
>>>>> Any comments on *Undertow Vs Netty* ? Am i doing wrong benchmark
>>>>> testing  ?? Should i change benchmark strategy ?
>>>>>
>>>>> --Senthil
>>>>>
>>>>> On Fri, Jul 7, 2017 at 3:14 PM, SenthilKumar K <senthilec566 at gmail.com
>>>>> > wrote:
>>>>>
>>>>>> Sorry for delay in responding to this thread!
>>>>>>
>>>>>> Thanks to everyone who helped me to Optimize Undertow Server.
>>>>>>
>>>>>> Here is the comparison after benchmarking my use case against Netty:
>>>>>>
>>>>>> *Undertow Vs Netty :*
>>>>>>
>>>>>> Test Case 1 :
>>>>>> Simple Request Response ( No Kafka ):
>>>>>>
>>>>>> *Undertow:*
>>>>>> Running 10m test @ http://198.18.134.13:8009/
>>>>>>   500 threads and 5000 connections
>>>>>>   Thread Stats   Avg      Stdev     Max   +/- Stdev
>>>>>>     Latency     *3.52m *    2.64m    8.96m    54.63%
>>>>>>     Req/Sec   376.58    103.18     0.99k    80.53%
>>>>>>   111628942 requests in 10.00m, 13.72GB read
>>>>>>   Socket errors: connect 0, read 28, write 0, timeout 2
>>>>>> Requests/sec: *186122.56*
>>>>>> Transfer/sec:     23.43MB
>>>>>>
>>>>>> *Netty:*
>>>>>> Running 10m test @ http://198.18.134.13:8009/
>>>>>> 500 threads and 5000 connections
>>>>>> Thread Stats   Avg      Stdev     Max   +/- Stdev
>>>>>>     Latency     *3.77m*     2.10m    7.51m    57.73%
>>>>>>     Req/Sec   518.63     31.78   652.00     70.25%
>>>>>>   155406992 requests in 10.00m, 13.82GB read
>>>>>>   Socket errors: connect 0, read 49, write 0, timeout 0
>>>>>> Requests/sec: *259107*.30
>>>>>> Transfer/sec:     24.17MB
>>>>>>
>>>>>>
>>>>>> *Test Case 2:*
>>>>>> Request --> Read --> Send it Kafka :
>>>>>>
>>>>>> *Undertow:*
>>>>>> Running 10m test @ http://198.18.134.13:8009/
>>>>>> 500 threads and 5000 connections
>>>>>> Thread Stats   Avg      Stdev     Max   +/- Stdev
>>>>>>     Latency     *4.37m *    2.46m    8.72m    57.83%
>>>>>>     Req/Sec   267.32      5.17   287.00     74.52%
>>>>>>   80044045 requests in 10.00m, 9.84GB read
>>>>>>   Socket errors: connect 0, read 121, write 0, timeout 0
>>>>>> Requests/sec: *133459.79*
>>>>>> Transfer/sec:     16.80MB
>>>>>>
>>>>>> *Netty:*
>>>>>> Running 10m test @ http://198.18.134.13:8009/
>>>>>> 500 threads and 5000 connections
>>>>>> Thread Stats   Avg      Stdev     Max   +/- Stdev
>>>>>>     Latency     *3.78m *    2.10m    7.55m    57.79%
>>>>>>     Req/Sec   516.92     28.84   642.00     69.60%
>>>>>>   154770536 requests in 10.00m, 13.69GB read
>>>>>>   Socket errors: connect 0, read 11, write 0, timeout 101
>>>>>> Requests/sec: *258049.39*
>>>>>> Transfer/sec:     23.38MB
>>>>>>
>>>>>>
>>>>>>
>>>>>> CPU Usage:
>>>>>> *Undertow:*
>>>>>> [image: Inline image 1]
>>>>>>
>>>>>> *Netty:*
>>>>>> [image: Inline image 2]
>>>>>>
>>>>>>
>>>>>> --Senthil
>>>>>>
>>>>>> On Thu, Jun 29, 2017 at 7:34 AM, Bill O'Neil <bill at dartalley.com>
>>>>>> wrote:
>>>>>>
>>>>>>> 1. Can you run the benchmark with the kafka line commented out at
>>>>>>> first and then again with it not commented out?
>>>>>>> 2. What rates were you getting with Jetty and Netty?
>>>>>>> 3. Are you running the tests from the same machine or a different
>>>>>>> one? If its the same machine and its using 20 threads they will be
>>>>>>> contending with undertows IO threads.
>>>>>>> 4. You can probably ignore the POST check if thats all your going to
>>>>>>> accept and its not a public api.
>>>>>>>
>>>>>>> import io.undertow.server.HttpHandler;
>>>>>>> import io.undertow.server.HttpServerExchange;
>>>>>>> import io.undertow.util.Headers;
>>>>>>> import io.undertow.util.Methods;
>>>>>>>
>>>>>>> public class DLRHandler implements HttpHandler {
>>>>>>>
>>>>>>>     final public static String _SUCCESS="SUCCESS";
>>>>>>>     final public static String _FAILURE="FAILURE";
>>>>>>>     final PostToKafka post2Kafka = new PostToKafka();
>>>>>>>
>>>>>>>     @Override
>>>>>>>     public void handleRequest( final HttpServerExchange exchange)
>>>>>>> throws Exception {
>>>>>>>         if (exchange.getRequestMethod().equals(Methods.POST)) {
>>>>>>>               exchange.getRequestReceiver().receiveFullString((
>>>>>>> exchangeReq, data) -> {
>>>>>>>                   //post2Kafka.write2Kafka(data); // write it to
>>>>>>> Kafka
>>>>>>>                   exchangeReq.getResponseHeaders().put(Headers.CONTENT_TYPE,
>>>>>>> "text/plain");
>>>>>>>                   exchangeReq.getResponseSender().send(_SUCCESS);
>>>>>>>               },
>>>>>>>              (exchangeReq, exception) -> {
>>>>>>>                  exchangeReq.getResponseHeaders().put(Headers.CONTENT_TYPE,
>>>>>>> "text/plain");
>>>>>>>                  exchangeReq.getResponseSender().send(_FAILURE);
>>>>>>>             });
>>>>>>>          }else{
>>>>>>>              throw new Exception("Method GET not supported by Server
>>>>>>> ");
>>>>>>>          }
>>>>>>>     }
>>>>>>> }
>>>>>>>
>>>>>>> On Wed, Jun 28, 2017 at 6:59 PM, Stuart Douglas <sdouglas at redhat.com
>>>>>>> > wrote:
>>>>>>>
>>>>>>>> The multiple dispatches() are unnecessary (well the second one to
>>>>>>>> the
>>>>>>>> IO thread is definitely unnecessary, the first one is only required
>>>>>>>> if
>>>>>>>> post2Kafka.write2Kafka(data); is a blocking operation and needs to
>>>>>>>> be
>>>>>>>> executed in a worker thread).
>>>>>>>>
>>>>>>>> Stuart
>>>>>>>>
>>>>>>>> On Wed, Jun 28, 2017 at 5:42 PM, SenthilKumar K <
>>>>>>>> senthilec566 at gmail.com> wrote:
>>>>>>>> > After modifying the code below i  could see the improvement ( not
>>>>>>>> much
>>>>>>>> > slightly ) in server - 65k req/sec.
>>>>>>>> >
>>>>>>>> > import io.undertow.server.HttpHandler;
>>>>>>>> > import io.undertow.server.HttpServerExchange;
>>>>>>>> > import io.undertow.util.Headers;
>>>>>>>> > import io.undertow.util.Methods;
>>>>>>>> >
>>>>>>>> > public class DLRHandler implements HttpHandler {
>>>>>>>> >
>>>>>>>> >     final public static String _SUCCESS="SUCCESS";
>>>>>>>> >     final public static String _FAILURE="FAILURE";
>>>>>>>> >     final PostToKafka post2Kafka = new PostToKafka();
>>>>>>>> >
>>>>>>>> >     @Override
>>>>>>>> >     public void handleRequest( final HttpServerExchange exchange)
>>>>>>>> throws
>>>>>>>> > Exception {
>>>>>>>> >         if (exchange.getRequestMethod().equals(Methods.POST)) {
>>>>>>>> >                 exchange.getRequestReceiver().receiveFullString((
>>>>>>>> > exchangeReq, data) -> {
>>>>>>>> >                   exchangeReq.dispatch(() -> {
>>>>>>>> >                       post2Kafka.write2Kafka(data); // write it
>>>>>>>> to Kafka
>>>>>>>> >                       exchangeReq.dispatch(exchangeReq.getIoThread(),
>>>>>>>> () ->
>>>>>>>> > {
>>>>>>>> >
>>>>>>>> > exchangeReq.getResponseHeaders().put(Headers.CONTENT_TYPE,
>>>>>>>> "text/plain");
>>>>>>>> >                           exchangeReq.getResponseSender
>>>>>>>> ().send(_SUCCESS);
>>>>>>>> >                       });
>>>>>>>> >                   });
>>>>>>>> >               },
>>>>>>>> >              (exchangeReq, exception) -> {
>>>>>>>> >                  exchangeReq.getResponseHeaders
>>>>>>>> ().put(Headers.CONTENT_TYPE,
>>>>>>>> > "text/plain");
>>>>>>>> >                  exchangeReq.getResponseSender().send(_FAILURE);
>>>>>>>> >             });
>>>>>>>> >          }else{
>>>>>>>> >              throw new Exception("Method GET not supported by
>>>>>>>> Server ");
>>>>>>>> >          }
>>>>>>>> >     }
>>>>>>>> > }
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > Pls review this and let me know if i'm doing anything wrong here
>>>>>>>> ...
>>>>>>>> > --Senthil
>>>>>>>> >
>>>>>>>> > On Fri, Jun 23, 2017 at 1:30 PM, Antoine Girard <
>>>>>>>> antoine.girard at ymail.com>
>>>>>>>> > wrote:
>>>>>>>> >>
>>>>>>>> >> Also, to come back on the JVM warmup, this will give you enough
>>>>>>>> answers:
>>>>>>>> >>
>>>>>>>> >> https://stackoverflow.com/questions/36198278/why-does-the-jv
>>>>>>>> m-require-warmup
>>>>>>>> >>
>>>>>>>> >> For your, it means that you have to run your tests for a few
>>>>>>>> minutes
>>>>>>>> >> before starting your actual measurements.
>>>>>>>> >>
>>>>>>>> >> I am also interested about how Netty / Jetty perform under the
>>>>>>>> same
>>>>>>>> >> conditions, please post!
>>>>>>>> >>
>>>>>>>> >> Cheers,
>>>>>>>> >> Antoine
>>>>>>>> >>
>>>>>>>> >> On Fri, Jun 23, 2017 at 1:24 AM, Stuart Douglas <
>>>>>>>> sdouglas at redhat.com>
>>>>>>>> >> wrote:
>>>>>>>> >>>
>>>>>>>> >>> Are you actually testing with the 'System.out.println(" Received
>>>>>>>> >>> String ==> "+message);'. System.out is incredibly slow.
>>>>>>>> >>>
>>>>>>>> >>> Stuart
>>>>>>>> >>>
>>>>>>>> >>> On Fri, Jun 23, 2017 at 7:01 AM, SenthilKumar K <
>>>>>>>> senthilec566 at gmail.com>
>>>>>>>> >>> wrote:
>>>>>>>> >>> > Sorry , I'm not an expert in JVM .. How do we do Warm Up JVM ?
>>>>>>>> >>> >
>>>>>>>> >>> > Here is the JVM args to Server:
>>>>>>>> >>> >
>>>>>>>> >>> > nohup java -Xmx4g -Xms4g -XX:MetaspaceSize=96m -XX:+UseG1GC
>>>>>>>> >>> > -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35
>>>>>>>> >>> > -XX:G1HeapRegionSize=16M -XX:MinMetaspaceFreeRatio=50
>>>>>>>> >>> > -XX:MaxMetaspaceFreeRatio=80 -cp undertow-0.0.1.jar
>>>>>>>> HelloWorldServer
>>>>>>>> >>> >
>>>>>>>> >>> >
>>>>>>>> >>> > --Senthil
>>>>>>>> >>> >
>>>>>>>> >>> >
>>>>>>>> >>> > On Fri, Jun 23, 2017 at 2:23 AM, Antoine Girard
>>>>>>>> >>> > <antoine.girard at ymail.com>
>>>>>>>> >>> > wrote:
>>>>>>>> >>> >>
>>>>>>>> >>> >> Do you warm up your jvm prior to the testing?
>>>>>>>> >>> >>
>>>>>>>> >>> >> Cheers,
>>>>>>>> >>> >> Antoine
>>>>>>>> >>> >>
>>>>>>>> >>> >> On Thu, Jun 22, 2017 at 10:42 PM, SenthilKumar K
>>>>>>>> >>> >> <senthilec566 at gmail.com>
>>>>>>>> >>> >> wrote:
>>>>>>>> >>> >>>
>>>>>>>> >>> >>> Thanks Bill n Antoine ..
>>>>>>>> >>> >>>
>>>>>>>> >>> >>>
>>>>>>>> >>> >>> Here is the updated one : ( tried without Kafka API ) .
>>>>>>>> >>> >>>
>>>>>>>> >>> >>> public class HelloWorldServer {
>>>>>>>> >>> >>>
>>>>>>>> >>> >>> public static void main(final String[] args) {
>>>>>>>> >>> >>> Undertow server = Undertow.builder().addHttpListener(8009,
>>>>>>>> >>> >>> "localhost").setHandler(new HttpHandler() {
>>>>>>>> >>> >>> @Override
>>>>>>>> >>> >>> public void handleRequest(final HttpServerExchange
>>>>>>>> exchange) throws
>>>>>>>> >>> >>> Exception {
>>>>>>>> >>> >>> if (exchange.getRequestMethod().equals(Methods.POST)) {
>>>>>>>> >>> >>> exchange.getRequestReceiver().receiveFullString(new
>>>>>>>> >>> >>> Receiver.FullStringCallback() {
>>>>>>>> >>> >>>                    @Override
>>>>>>>> >>> >>>                    public void handle(HttpServerExchange
>>>>>>>> exchange,
>>>>>>>> >>> >>> String
>>>>>>>> >>> >>> message) {
>>>>>>>> >>> >>>                     System.out.println(" Received String ==>
>>>>>>>> >>> >>> "+message);
>>>>>>>> >>> >>>                        exchange.getResponseSender().s
>>>>>>>> end(message);
>>>>>>>> >>> >>>                    }
>>>>>>>> >>> >>>                });
>>>>>>>> >>> >>> } else {
>>>>>>>> >>> >>> exchange.getResponseHeaders().put(Headers.CONTENT_TYPE,
>>>>>>>> >>> >>> "text/plain");
>>>>>>>> >>> >>> exchange.getResponseSender().send("FAILURE");
>>>>>>>> >>> >>> }
>>>>>>>> >>> >>> }
>>>>>>>> >>> >>> }).build();
>>>>>>>> >>> >>> server.start();
>>>>>>>> >>> >>> }
>>>>>>>> >>> >>> }
>>>>>>>> >>> >>>
>>>>>>>> >>> >>>
>>>>>>>> >>> >>> Oops seems to no improvement :
>>>>>>>> >>> >>>
>>>>>>>> >>> >>> Running 1m test @ http://localhost:8009/
>>>>>>>> >>> >>>   100 threads and 1000 connections
>>>>>>>> >>> >>>   Thread Stats   Avg      Stdev     Max   +/- Stdev
>>>>>>>> >>> >>>     Latency    25.79ms   22.18ms 289.48ms   67.66%
>>>>>>>> >>> >>>     Req/Sec   437.76     61.71     2.30k    80.26%
>>>>>>>> >>> >>>   Latency Distribution
>>>>>>>> >>> >>>      50%   22.60ms
>>>>>>>> >>> >>>      75%   37.83ms
>>>>>>>> >>> >>>      90%   55.32ms
>>>>>>>> >>> >>>      99%   90.47ms
>>>>>>>> >>> >>>   2625607 requests in 1.00m, 2.76GB read
>>>>>>>> >>> >>> Requests/sec:  43688.42
>>>>>>>> >>> >>> Transfer/sec:     47.08MB
>>>>>>>> >>> >>>
>>>>>>>> >>> >>>
>>>>>>>> >>> >>> :-( :-( ..
>>>>>>>> >>> >>>
>>>>>>>> >>> >>>
>>>>>>>> >>> >>> --Senthil
>>>>>>>> >>> >>>
>>>>>>>> >>> >>>
>>>>>>>> >>> >>> On Fri, Jun 23, 2017 at 1:47 AM, Antoine Girard
>>>>>>>> >>> >>> <antoine.girard at ymail.com> wrote:
>>>>>>>> >>> >>>>
>>>>>>>> >>> >>>> You can use the Receiver API, specifically for that
>>>>>>>> purpose.
>>>>>>>> >>> >>>> On the exchange, call: getRequestReceiver();
>>>>>>>> >>> >>>>
>>>>>>>> >>> >>>> You will get a receiver object:
>>>>>>>> >>> >>>>
>>>>>>>> >>> >>>>
>>>>>>>> >>> >>>> https://github.com/undertow-io
>>>>>>>> /undertow/blob/master/core/src/main/java/io/undertow/io/Rece
>>>>>>>> iver.java
>>>>>>>> >>> >>>>
>>>>>>>> >>> >>>> On the receiver you can call: receiveFullString, you have
>>>>>>>> to pass it
>>>>>>>> >>> >>>> a
>>>>>>>> >>> >>>> callback that will be called when the whole body has been
>>>>>>>> read.
>>>>>>>> >>> >>>>
>>>>>>>> >>> >>>> Please share your results when you test this further!
>>>>>>>> >>> >>>>
>>>>>>>> >>> >>>> Cheers,
>>>>>>>> >>> >>>> Antoine
>>>>>>>> >>> >>>>
>>>>>>>> >>> >>>>
>>>>>>>> >>> >>>> On Thu, Jun 22, 2017 at 8:27 PM, SenthilKumar K
>>>>>>>> >>> >>>> <senthilec566 at gmail.com>
>>>>>>>> >>> >>>> wrote:
>>>>>>>> >>> >>>>>
>>>>>>>> >>> >>>>> Seems to Reading Request body is wrong , So what is the
>>>>>>>> efficient
>>>>>>>> >>> >>>>> way
>>>>>>>> >>> >>>>> of reading request body in undertow ?
>>>>>>>> >>> >>>>>
>>>>>>>> >>> >>>>> --Senthil
>>>>>>>> >>> >>>>>
>>>>>>>> >>> >>>>> On Thu, Jun 22, 2017 at 11:30 PM, SenthilKumar K
>>>>>>>> >>> >>>>> <senthilec566 at gmail.com> wrote:
>>>>>>>> >>> >>>>>>
>>>>>>>> >>> >>>>>> Hello Undertow Dev Team ,
>>>>>>>> >>> >>>>>>
>>>>>>>> >>> >>>>>>       I have been working on the use case where i should
>>>>>>>> create
>>>>>>>> >>> >>>>>> simple
>>>>>>>> >>> >>>>>> http server to serve 1.5 Million Requests per Second per
>>>>>>>> Instance
>>>>>>>> >>> >>>>>> ..
>>>>>>>> >>> >>>>>>
>>>>>>>> >>> >>>>>>
>>>>>>>> >>> >>>>>> Here is the benchmark result of Undertow :
>>>>>>>> >>> >>>>>>
>>>>>>>> >>> >>>>>> Running 1m test @ http://127.0.0.1:8009/
>>>>>>>> >>> >>>>>>   20 threads and 40 connections
>>>>>>>> >>> >>>>>>   Thread Stats   Avg      Stdev     Max   +/- Stdev
>>>>>>>> >>> >>>>>>     Latency     2.51ms   10.75ms 282.22ms   99.28%
>>>>>>>> >>> >>>>>>     Req/Sec     1.12k   316.65     1.96k    54.50%
>>>>>>>> >>> >>>>>>   Latency Distribution
>>>>>>>> >>> >>>>>>      50%    1.43ms
>>>>>>>> >>> >>>>>>      75%    2.38ms
>>>>>>>> >>> >>>>>>      90%    2.90ms
>>>>>>>> >>> >>>>>>      99%   10.45ms
>>>>>>>> >>> >>>>>>   1328133 requests in 1.00m, 167.19MB read
>>>>>>>> >>> >>>>>> Requests/sec:  22127.92
>>>>>>>> >>> >>>>>> Transfer/sec:      2.79MB
>>>>>>>> >>> >>>>>>
>>>>>>>> >>> >>>>>> This is less compared to other frameworks like Jetty and
>>>>>>>> Netty ..
>>>>>>>> >>> >>>>>> But
>>>>>>>> >>> >>>>>> originally Undertow is high performant http server ..
>>>>>>>> >>> >>>>>>
>>>>>>>> >>> >>>>>> Hardware details:
>>>>>>>> >>> >>>>>> Xeon CPU E3-1270 v5 machine with 4 cores ( Clock 100
>>>>>>>> MHz, Capacity
>>>>>>>> >>> >>>>>> 4
>>>>>>>> >>> >>>>>> GHz) , Memory : 32 G , Available memory 31 G.
>>>>>>>> >>> >>>>>>
>>>>>>>> >>> >>>>>> I would need Undertow experts to review the server code
>>>>>>>> below and
>>>>>>>> >>> >>>>>> advice me on tuning to achieve my goal( ~1.5 Million
>>>>>>>> requests/sec
>>>>>>>> >>> >>>>>> ).
>>>>>>>> >>> >>>>>>
>>>>>>>> >>> >>>>>> Server :
>>>>>>>> >>> >>>>>>
>>>>>>>> >>> >>>>>> Undertow server = Undertow.builder()
>>>>>>>> >>> >>>>>>                .addHttpListener(8009, "localhost")
>>>>>>>> >>> >>>>>>                .setHandler(new Handler()).build();
>>>>>>>> >>> >>>>>> server.start();
>>>>>>>> >>> >>>>>>
>>>>>>>> >>> >>>>>>
>>>>>>>> >>> >>>>>> Handler.Java
>>>>>>>> >>> >>>>>>
>>>>>>>> >>> >>>>>>     final Pooled<ByteBuffer> pooledByteBuffer =
>>>>>>>> >>> >>>>>>
>>>>>>>> >>> >>>>>> exchange.getConnection().getBufferPool().allocate();
>>>>>>>> >>> >>>>>> final ByteBuffer byteBuffer =
>>>>>>>> pooledByteBuffer.getResource();
>>>>>>>> >>> >>>>>>    byteBuffer.clear();
>>>>>>>> >>> >>>>>>    exchange.getRequestChannel().read(byteBuffer);
>>>>>>>> >>> >>>>>>    int pos = byteBuffer.position();
>>>>>>>> >>> >>>>>>    byteBuffer.rewind();
>>>>>>>> >>> >>>>>>    byte[] bytes = new byte[pos];
>>>>>>>> >>> >>>>>>    byteBuffer.get(bytes);
>>>>>>>> >>> >>>>>>    String requestBody = new String(bytes,
>>>>>>>> Charset.forName("UTF-8")
>>>>>>>> >>> >>>>>> );
>>>>>>>> >>> >>>>>>    byteBuffer.clear();
>>>>>>>> >>> >>>>>>    pooledByteBuffer.free();
>>>>>>>> >>> >>>>>>    final PostToKafka post2Kafka = new PostToKafka();
>>>>>>>> >>> >>>>>> try {
>>>>>>>> >>> >>>>>> post2Kafka.write2Kafka(requestBody);  { This API can
>>>>>>>> handle  ~2
>>>>>>>> >>> >>>>>> Millions events per sec }
>>>>>>>> >>> >>>>>> } catch (Exception e) {
>>>>>>>> >>> >>>>>> e.printStackTrace();
>>>>>>>> >>> >>>>>> }
>>>>>>>> >>> >>>>>>     exchange.getResponseHeaders()
>>>>>>>> .put(Headers.CONTENT_TYPE,
>>>>>>>> >>> >>>>>> "text/plain");
>>>>>>>> >>> >>>>>>     exchange.getResponseSender().send("SUCCESS");
>>>>>>>> >>> >>>>>>
>>>>>>>> >>> >>>>>>
>>>>>>>> >>> >>>>>> --Senthil
>>>>>>>> >>> >>>>>
>>>>>>>> >>> >>>>>
>>>>>>>> >>> >>>>>
>>>>>>>> >>> >>>>> _______________________________________________
>>>>>>>> >>> >>>>> 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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> undertow-dev mailing list
>>>>> undertow-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>
>>>> --
>>>> Med venlig hilsen / Best regards
>>>>
>>>> *Kim Rasmussen*
>>>> Partner, IT Architect
>>>>
>>>> *Asseco Denmark A/S*
>>>> Kronprinsessegade 54
>>>> DK-1306 Copenhagen K
>>>> Mobile: +45 26 16 40 23 <+45%2026%2016%2040%2023>
>>>> Ph.: +45 33 36 46 60 <+45%2033%2036%2046%2060>
>>>> Fax: +45 33 36 46 61 <+45%2033%2036%2046%2061>
>>>>
>>>
>>> _______________________________________________
>>> undertow-dev mailing list
>>> undertow-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170713/f97d68d1/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 31196 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20170713/f97d68d1/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 25115 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20170713/f97d68d1/attachment-0003.png 

From sdouglas at redhat.com  Wed Jul 12 19:33:03 2017
From: sdouglas at redhat.com (Stuart Douglas)
Date: Thu, 13 Jul 2017 11:33:03 +1200
Subject: [undertow-dev] Best practice for receiving/writing HTTP body by
	chunks
In-Reply-To: <CAG-POd2mEEGFyP1wu6HvsPCbcXTfvM=g8Q32dxUXdB2LEZnTOQ@mail.gmail.com>
References: <CAG-POd2mEEGFyP1wu6HvsPCbcXTfvM=g8Q32dxUXdB2LEZnTOQ@mail.gmail.com>
Message-ID: <CAD+L2cxKU_p54itwoK4fdz6FK7xpMD-VSsWC-t7bDrWVC-e-=A@mail.gmail.com>

getResponseSender().send(bodyByteBuffer, myIoCallback) should
definitely be invoking the IO callback. Do you have a reproducer for
the case where it does not?

Stuart

On Mon, Jul 10, 2017 at 9:31 PM, Eldad Rudich <eldadru at gmail.com> wrote:
> Hi,
>
> I'm implementing custom HTTP reverse proxy using Undertow.
> My server is listening to requests and when a new request arrives, It wraps
> the request in a proprietary protocol and redirect to another component in
> my system.
> That component takes the request data, unpack it, send it to the actual web
> server, get's the response and send the response back to my Undertow server
> in the same proprietary protocol.
> The server unpacks the response and writes it back to the user's browser.
>
> All works very well for "small" requests/response but for request/response
> that has body data that exceed some predefined amount I would like to split
> the request/response to chunks ( my own chunking mechanism, not related to
> HTTP chunking) to better handle such scenarios and not hold the entire data
> in the server's memory.
>
> In order to do that I need access to the request/response body bytes,
> I came by this thread:
> http://lists.jboss.org/pipermail/undertow-dev/2015-January/001080.html and
> tried to implement both proposed solutions
>
> When I used the async interface:
>
> HttpServerExchange.getResponseSender().send(bodyByteBuffer, myIoCallback)
>
> Sometimes my callback just not called ( nor the onComplete or the
> onException callbacks) for unknown reasons.
>
> So I tried the blocking interface instead ( from dispatched handler ):
>
> HttpServerExchange.startBlocking()
>
> HttpServerExchange.getResponseSender().send(bodyByteBuffer)
>
> That works but I read somewhere in this mailing list that the async
> interface is more efficient.
>
> The same behavior occurred when trying to receive the request body using:
> HttpServerExchange.getRequestReceiver()
> and also solved using the blocking interface.
>
> Am I missing something? what are the best practices for reading/writing
> partial request/response body?
>
> Best,
> Eldad.
>
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From kr at asseco.dk  Mon Jul 17 09:23:24 2017
From: kr at asseco.dk (Kim Rasmussen)
Date: Mon, 17 Jul 2017 15:23:24 +0200
Subject: [undertow-dev] Using undertow client with proxy servers
Message-ID: <CAGX6Y=2+R6JA36fNR9zTKgfFO9=3pOfmoLS1p0kHQQVD1Xv==w@mail.gmail.com>

Hi,

I have a usecase where I have a reverse proxy that uses a customized
ProxyHandler - for some hosts, I need to proxy the requests onwards via a
proxy server - e.g. a bluecoat proxy.

So something like this:
Browser --> Undertow reverse proxy --> Bluecoat Proxy --> Web server

So, I need to use the undertow client with a (non-reverse) proxy server.

I am guessing that with a ClientRequest, for non-ssl requests I should just
be able to change the path from /mypath to http://my.server.name/mypath
before sending it to the proxy server instead of to the destination host
directly.

But what would be the ideal way of handling this when I need SSL so I need
to wrap the requests inside a "CONNECT my.server.name:443 HTTP/1.1" block
before starting the SSL negotiation ? Any pointers ?

Would creating a specific ClientProvider be a sensible way ?

-- 
Med venlig hilsen / Best regards

*Kim Rasmussen*
Partner, IT Architect

*Asseco Denmark A/S*
Kronprinsessegade 54
DK-1306 Copenhagen K
Mobile: +45 26 16 40 23
Ph.: +45 33 36 46 60
Fax: +45 33 36 46 61
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170717/30d2cb2a/attachment.html 

From sdouglas at redhat.com  Tue Jul 18 00:05:46 2017
From: sdouglas at redhat.com (Stuart Douglas)
Date: Tue, 18 Jul 2017 16:05:46 +1200
Subject: [undertow-dev] Using undertow client with proxy servers
In-Reply-To: <CAGX6Y=2+R6JA36fNR9zTKgfFO9=3pOfmoLS1p0kHQQVD1Xv==w@mail.gmail.com>
References: <CAGX6Y=2+R6JA36fNR9zTKgfFO9=3pOfmoLS1p0kHQQVD1Xv==w@mail.gmail.com>
Message-ID: <CAD+L2cy37ZGPaFJ8+G8_enaSm_UHaFg3Q=3=y=4SCCfMw-083g@mail.gmail.com>

io.undertow.websockets.client.WebSocketClient contains an example of
how to use the CONNECT method, although we don't currently have any
way of then using the client over the created connection.

I think that ideally this would be implemented by enhancing the
existing client implementations, you should not really need a new
ClientProvider as the only real difference is in the connection
establishment.

Stuart

On Tue, Jul 18, 2017 at 1:23 AM, Kim Rasmussen <kr at asseco.dk> wrote:
> Hi,
>
> I have a usecase where I have a reverse proxy that uses a customized
> ProxyHandler - for some hosts, I need to proxy the requests onwards via a
> proxy server - e.g. a bluecoat proxy.
>
> So something like this:
> Browser --> Undertow reverse proxy --> Bluecoat Proxy --> Web server
>
> So, I need to use the undertow client with a (non-reverse) proxy server.
>
> I am guessing that with a ClientRequest, for non-ssl requests I should just
> be able to change the path from /mypath to http://my.server.name/mypath
> before sending it to the proxy server instead of to the destination host
> directly.
>
> But what would be the ideal way of handling this when I need SSL so I need
> to wrap the requests inside a "CONNECT my.server.name:443 HTTP/1.1" block
> before starting the SSL negotiation ? Any pointers ?
>
> Would creating a specific ClientProvider be a sensible way ?
>
> --
> Med venlig hilsen / Best regards
>
> Kim Rasmussen
> Partner, IT Architect
>
> Asseco Denmark A/S
> Kronprinsessegade 54
> DK-1306 Copenhagen K
> Mobile: +45 26 16 40 23
> Ph.: +45 33 36 46 60
> Fax: +45 33 36 46 61
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From kr at asseco.dk  Tue Jul 18 03:11:50 2017
From: kr at asseco.dk (Kim Rasmussen)
Date: Tue, 18 Jul 2017 09:11:50 +0200
Subject: [undertow-dev] Using undertow client with proxy servers
In-Reply-To: <CAD+L2cy37ZGPaFJ8+G8_enaSm_UHaFg3Q=3=y=4SCCfMw-083g@mail.gmail.com>
References: <CAGX6Y=2+R6JA36fNR9zTKgfFO9=3pOfmoLS1p0kHQQVD1Xv==w@mail.gmail.com>
	<CAD+L2cy37ZGPaFJ8+G8_enaSm_UHaFg3Q=3=y=4SCCfMw-083g@mail.gmail.com>
Message-ID: <CAGX6Y=0zODrAUR+tpgdwGxLYnPOZqotMrodvvS=PQH8LcYrVOw@mail.gmail.com>

Thanks Stuart,

I've created a JIRA issue to track it here:
https://issues.jboss.org/browse/UNDERTOW-1138 Do you think it is something
you want to implement and have time to do within a reasonable timeframe ?
or should I try to get it done myself ?

Thanks
/Kim



2017-07-18 6:05 GMT+02:00 Stuart Douglas <sdouglas at redhat.com>:

> io.undertow.websockets.client.WebSocketClient contains an example of
> how to use the CONNECT method, although we don't currently have any
> way of then using the client over the created connection.
>
> I think that ideally this would be implemented by enhancing the
> existing client implementations, you should not really need a new
> ClientProvider as the only real difference is in the connection
> establishment.
>
> Stuart
>
> On Tue, Jul 18, 2017 at 1:23 AM, Kim Rasmussen <kr at asseco.dk> wrote:
> > Hi,
> >
> > I have a usecase where I have a reverse proxy that uses a customized
> > ProxyHandler - for some hosts, I need to proxy the requests onwards via a
> > proxy server - e.g. a bluecoat proxy.
> >
> > So something like this:
> > Browser --> Undertow reverse proxy --> Bluecoat Proxy --> Web server
> >
> > So, I need to use the undertow client with a (non-reverse) proxy server.
> >
> > I am guessing that with a ClientRequest, for non-ssl requests I should
> just
> > be able to change the path from /mypath to http://my.server.name/mypath
> > before sending it to the proxy server instead of to the destination host
> > directly.
> >
> > But what would be the ideal way of handling this when I need SSL so I
> need
> > to wrap the requests inside a "CONNECT my.server.name:443 HTTP/1.1"
> block
> > before starting the SSL negotiation ? Any pointers ?
> >
> > Would creating a specific ClientProvider be a sensible way ?
> >
> > --
> > Med venlig hilsen / Best regards
> >
> > Kim Rasmussen
> > Partner, IT Architect
> >
> > Asseco Denmark A/S
> > Kronprinsessegade 54
> > DK-1306 Copenhagen K
> > Mobile: +45 26 16 40 23
> > Ph.: +45 33 36 46 60
> > Fax: +45 33 36 46 61
> >
> >
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>



-- 
Med venlig hilsen / Best regards

*Kim Rasmussen*
Partner, IT Architect

*Asseco Denmark A/S*
Kronprinsessegade 54
DK-1306 Copenhagen K
Mobile: +45 26 16 40 23
Ph.: +45 33 36 46 60
Fax: +45 33 36 46 61
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170718/3ae5f7bf/attachment.html 

From sdouglas at redhat.com  Wed Jul 19 01:50:21 2017
From: sdouglas at redhat.com (Stuart Douglas)
Date: Wed, 19 Jul 2017 17:50:21 +1200
Subject: [undertow-dev] Using undertow client with proxy servers
In-Reply-To: <CAGX6Y=0zODrAUR+tpgdwGxLYnPOZqotMrodvvS=PQH8LcYrVOw@mail.gmail.com>
References: <CAGX6Y=2+R6JA36fNR9zTKgfFO9=3pOfmoLS1p0kHQQVD1Xv==w@mail.gmail.com>
	<CAD+L2cy37ZGPaFJ8+G8_enaSm_UHaFg3Q=3=y=4SCCfMw-083g@mail.gmail.com>
	<CAGX6Y=0zODrAUR+tpgdwGxLYnPOZqotMrodvvS=PQH8LcYrVOw@mail.gmail.com>
Message-ID: <CAD+L2cw6fnE8GOBgjsg0KWKT51rqFn4Q3juVDeNPBUmSowJBqw@mail.gmail.com>

I am unlikely to get to it in the short term.

Stuart

On Tue, Jul 18, 2017 at 7:11 PM, Kim Rasmussen <kr at asseco.dk> wrote:
> Thanks Stuart,
>
> I've created a JIRA issue to track it here:
> https://issues.jboss.org/browse/UNDERTOW-1138 Do you think it is something
> you want to implement and have time to do within a reasonable timeframe ? or
> should I try to get it done myself ?
>
> Thanks
> /Kim
>
>
>
> 2017-07-18 6:05 GMT+02:00 Stuart Douglas <sdouglas at redhat.com>:
>>
>> io.undertow.websockets.client.WebSocketClient contains an example of
>> how to use the CONNECT method, although we don't currently have any
>> way of then using the client over the created connection.
>>
>> I think that ideally this would be implemented by enhancing the
>> existing client implementations, you should not really need a new
>> ClientProvider as the only real difference is in the connection
>> establishment.
>>
>> Stuart
>>
>> On Tue, Jul 18, 2017 at 1:23 AM, Kim Rasmussen <kr at asseco.dk> wrote:
>> > Hi,
>> >
>> > I have a usecase where I have a reverse proxy that uses a customized
>> > ProxyHandler - for some hosts, I need to proxy the requests onwards via
>> > a
>> > proxy server - e.g. a bluecoat proxy.
>> >
>> > So something like this:
>> > Browser --> Undertow reverse proxy --> Bluecoat Proxy --> Web server
>> >
>> > So, I need to use the undertow client with a (non-reverse) proxy server.
>> >
>> > I am guessing that with a ClientRequest, for non-ssl requests I should
>> > just
>> > be able to change the path from /mypath to http://my.server.name/mypath
>> > before sending it to the proxy server instead of to the destination host
>> > directly.
>> >
>> > But what would be the ideal way of handling this when I need SSL so I
>> > need
>> > to wrap the requests inside a "CONNECT my.server.name:443 HTTP/1.1"
>> > block
>> > before starting the SSL negotiation ? Any pointers ?
>> >
>> > Would creating a specific ClientProvider be a sensible way ?
>> >
>> > --
>> > Med venlig hilsen / Best regards
>> >
>> > Kim Rasmussen
>> > Partner, IT Architect
>> >
>> > Asseco Denmark A/S
>> > Kronprinsessegade 54
>> > DK-1306 Copenhagen K
>> > Mobile: +45 26 16 40 23
>> > Ph.: +45 33 36 46 60
>> > Fax: +45 33 36 46 61
>> >
>> >
>> > _______________________________________________
>> > undertow-dev mailing list
>> > undertow-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>
>
>
>
> --
> Med venlig hilsen / Best regards
>
> Kim Rasmussen
> Partner, IT Architect
>
> Asseco Denmark A/S
> Kronprinsessegade 54
> DK-1306 Copenhagen K
> Mobile: +45 26 16 40 23
> Ph.: +45 33 36 46 60
> Fax: +45 33 36 46 61

From slavastap at gmail.com  Thu Jul 27 05:58:54 2017
From: slavastap at gmail.com (=?UTF-8?B?0JLRj9GH0LXRgdC70LDQsiDQkA==?=)
Date: Thu, 27 Jul 2017 12:58:54 +0300
Subject: [undertow-dev] Occurrence of write timeout on client\server side
Message-ID: <CANO169Lf19YdFF6H4+PxiNjj92aMr6y+UxcKsDmJ05+LbfoyCA@mail.gmail.com>

Hello.
I can't understand how "Write Timeout" works and when this timeout happens.
I am using undertow as part of WildFly appserver.
I can set Read Timeout as a small value (for example, 1 sec).
And then all request will be rejected and browser request will be marked as
closed (i can see this status in browser dev tools).

But nothing happens when i set a small value for Write Timeout. All my
request complete successfully.
I am using also "clumsy" for slow speed emulation.

I can see, that connection should be closed at break point:
io.undertow.conduits.WriteTimeoutStreamSinkConduit.handleWriteTimeout
I see, that "IoUtils.safeClose(this.connection)" called, but nothing
happens in browser.

Could you explain, please, how can i see the result of write timeout on
server or client (prefered) side.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170727/ff111d72/attachment.html 

From sdouglas at redhat.com  Mon Jul 31 19:21:49 2017
From: sdouglas at redhat.com (Stuart Douglas)
Date: Tue, 1 Aug 2017 11:21:49 +1200
Subject: [undertow-dev] Occurrence of write timeout on client\server side
In-Reply-To: <CANO169Lf19YdFF6H4+PxiNjj92aMr6y+UxcKsDmJ05+LbfoyCA@mail.gmail.com>
References: <CANO169Lf19YdFF6H4+PxiNjj92aMr6y+UxcKsDmJ05+LbfoyCA@mail.gmail.com>
Message-ID: <CAD+L2cyzS_VzoTmTq6fC1hG7U3nsh6OpiRrcU1ycWHAL_CUwYA@mail.gmail.com>

In order to see the effect of a write timeout you will need to attempt
to send a large response (e.g. 1mb), and have a client that does not
attempt to read from the socket (so the client sends the request,
keeps the connection open, but does not read the response).

Stuart

On Thu, Jul 27, 2017 at 9:58 PM, ???????? ? <slavastap at gmail.com> wrote:
> Hello.
> I can't understand how "Write Timeout" works and when this timeout happens.
> I am using undertow as part of WildFly appserver.
> I can set Read Timeout as a small value (for example, 1 sec).
> And then all request will be rejected and browser request will be marked as
> closed (i can see this status in browser dev tools).
>
> But nothing happens when i set a small value for Write Timeout. All my
> request complete successfully.
> I am using also "clumsy" for slow speed emulation.
>
> I can see, that connection should be closed at break point:
> io.undertow.conduits.WriteTimeoutStreamSinkConduit.handleWriteTimeout
> I see, that "IoUtils.safeClose(this.connection)" called, but nothing happens
> in browser.
>
> Could you explain, please, how can i see the result of write timeout on
> server or client (prefered) side.
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev