Transport config used for the above JFR:
-
id: "jaxrs-http"
host: "0.0.0.0"
port: 8080
bossThreadPoolSize: 1
workerThreadPoolSize: 16
parameters:
# -
# name: "execThreadPoolSize"
# value: 2048
-
name: "disruptor.buffer.size"
value: 1024
-
name: "disruptor.count"
value: 5
-
name: "disruptor.eventhandler.count"
value: 256
# -
# name: "disruptor.wait.strategy"
# value: "SLEEP_WAITING"
-
name: "share.disruptor.with.outbound"
value: false
-
name: "disruptor.consumer.external.worker.pool.size"
value: 256
On Fri, Mar 11, 2016 at 11:41 AM, Samiyuru Senarathne <samiy...@wso2.com>
wrote:
> Please find the attached JFR dump of MSF4J-carbon-message-disruptor test
> performed with following 'ab' config.
> An MSF4J service that 'consumes a 1KB and sleeps for 50ms before
> responding the same 1KB' is used as the service.
>
> ab -k -p 1kb_rand_data.txt -s 999 -c 400 -n 5000 -H "Accept:text/plain"
> http://204.13.85.2:8080/EchoService/echo
>
> AB Results Summary:
> Concurrency Level: 400
> Time taken for tests: 30.224 seconds
> Complete requests: 3000
> Failed requests: 0
> Keep-Alive requests: 3000
> Total transferred: 3345000 bytes
> Total body sent: 3609000
> HTML transferred: 3072000 bytes
> Requests per second: 99.26 [#/sec] (mean)
> Time per request: 4029.882 [ms] (mean)
> Time per request: 10.075 [ms] (mean, across all concurrent requests)
> Transfer rate: 108.08 [Kbytes/sec] received
> 116.61 kb/s sent
> 224.69 kb/s total
>
>
>
> On Fri, Mar 11, 2016 at 10:39 AM, Samiyuru Senarathne <samiy...@wso2.com>
> wrote:
>
>> Hi,
>>
>> Please find results of the tests I have done so far.
>>
>> https://docs.google.com/a/wso2.com/spreadsheets/d/16TXeXU022b5ILqkRsY3zZdnu2OiA3yWEN42xVL8eXa4/edit?usp=sharing
>>
>> MSF4J 1.0.0 section of this tests gives a good insight into the netty
>> thread behaviour. I focused a bit more on that because confirming the
>> practical behaviour of netty thread model is one of the first things we
>> should do.
>>
>> According to these results,
>>
>> - Increasing the netty boss pool does not make any difference.
>> - For the netty worker pool, it's enough to have a number of threads
>> equal to the number of cpus.
>> - Increasing the number of threads of the pool of the netty handler
>> that does the actual work increases the performance significantly for high
>> concurrency levels.
>>
>> Regarding the tests that include disruptor,
>> I applied the optimal configurations according to [1]. But I could not
>> get results even close to the results of GW and the results I got are bit
>> strange (99 TPS regardless of concurrency level). I think we should try
>> more variations of disruptor settings before coming to a conclusion.
>>
>> [1] -
>> https://docs.google.com/a/wso2.com/spreadsheets/d/1ck2O7eMkswJSQCgW8ciOkIyZkXGiZhIxRWNN-R9vgMk/edit?usp=sharing
>>
>> Best Regards,
>> Samiyuru
>>
>> On Fri, Mar 11, 2016 at 10:06 AM, Afkham Azeez <az...@wso2.com> wrote:
>>
>>> I think Samiyuru tested with that nrw worker pool & still the
>>> performance is unacceptable.
>>> On Mar 11, 2016 9:45 AM, "Isuru Ranawaka" <isu...@wso2.com> wrote:
>>>
>>>> Hi ,
>>>>
>>>> We have already added native worker pool for Disruptor and Samiyuru is
>>>> doing testing on that. We will make disruptor optional as well.
>>>>
>>>> thanks
>>>>
>>>> On Thu, Mar 10, 2016 at 9:29 AM, Kasun Indrasiri <ka...@wso2.com>
>>>> wrote:
>>>>
>>>>> Yes, we can make the disruptor optional. Also, we should try using the
>>>>> native worker pool for Event Handler[1], so that the Disruptor itself runs
>>>>> the event handler on a worker pool. We'll implement both approaches and do
>>>>> a comparison.
>>>>>
>>>>> [1]
>>>>> https://lmax-exchange.github.io/disruptor/docs/com/lmax/disruptor/dsl/Disruptor.html#handleEventsWithWorkerPool(com.lmax.disruptor.WorkHandler..
>>>>> .)
>>>>>
>>>>> On Thu, Mar 10, 2016 at 8:48 AM, Afkham Azeez <az...@wso2.com> wrote:
>>>>>
>>>>>> After upgrading to the new transport, we are seeing a significant
>>>>>> drop in performance for any service that take some time to execute. We
>>>>>> have
>>>>>> tried with the configuration used for the gateway which gave the best
>>>>>> figures on the same hardware. We have also noted that using a separate
>>>>>> dedicated executor thread pool, which is supported by Netty, gave much
>>>>>> better performance than the disruptor based implementation. Even in
>>>>>> theory,
>>>>>> disruptor cannot give better performance when used with a real service
>>>>>> that
>>>>>> does some real work, rather than doing passthrough, for example. Can we
>>>>>> improve the Netty transport to make going through disruptor optional?
>>>>>>
>>>>>> --
>>>>>> *Afkham Azeez*
>>>>>> Director of Architecture; WSO2, Inc.; http://wso2.com
>>>>>> Member; Apache Software Foundation; http://www.apache.org/
>>>>>> * <http://www.apache.org/>*
>>>>>> *email: **az...@wso2.com* <az...@wso2.com>
>>>>>> * cell: +94 77 3320919 <%2B94%2077%203320919>blog: *
>>>>>> *http://blog.afkham.org* <http://blog.afkham.org>
>>>>>> *twitter: **http://twitter.com/afkham_azeez*
>>>>>> <http://twitter.com/afkham_azeez>
>>>>>> *linked-in: **http://lk.linkedin.com/in/afkhamazeez
>>>>>> <http://lk.linkedin.com/in/afkhamazeez>*
>>>>>>
>>>>>> *Lean . Enterprise . Middleware*
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Kasun Indrasiri
>>>>> Software Architect
>>>>> WSO2, Inc.; http://wso2.com
>>>>> lean.enterprise.middleware
>>>>>
>>>>> cell: +94 77 556 5206
>>>>> Blog : http://kasunpanorama.blogspot.com/
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Best Regards
>>>> Isuru Ranawaka
>>>> M: +94714629880
>>>> Blog : http://isurur.blogspot.com/
>>>>
>>>
>>
>>
>> --
>> Samiyuru Senarathne
>> *Software Engineer*
>> Mobile : +94 (0) 71 134 6087
>> samiy...@wso2.com
>>
>
>
>
> --
> Samiyuru Senarathne
> *Software Engineer*
> Mobile : +94 (0) 71 134 6087
> samiy...@wso2.com
>
--
Samiyuru Senarathne
*Software Engineer*
Mobile : +94 (0) 71 134 6087
samiy...@wso2.com
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
