Interestingly I saw a performance improvement using optimizedForMultiplexing
with HTTP, although this potentially only affected my specific test
scenario (simple low latency echo). Also note that this was when using
worker threads, so not straight through using selectors.
Let me turn off optimizedForMultiplexing, give inbound 1 selector per core,
outbound 1 selector per core and see how this runs...
Dan
On Mon, Apr 13, 2015 at 11:44 PM, Oleksiy Stashok <
oleksiy.stashok_at_oracle.com> wrote:
>
>
>
>> - Even if the same selector pool is configured for inbound and
>> outbound, during response processing then Grizzly will still do a thread
>> handover before sending response to client because of the use of
>> AsyncQueueIO. This right?
>>
>> Not sure I understand this, IMO there won't be any extra thread handover
>> involved.
>>
>
> I was referring to the AsyncWriteQueue. Currently I
> have 'optimizedForMultiplexing' set true which I thought I'd seen
> previsouly disabled the direct writing as you described further on in your
> email. Pherhaps I should try without this flag though.
>
> Right, optimizedForMultiplexing is useful, when you concurrently write
> packets to the connection, which is not the case with HTTP, unless it's
> HTTP 2.0 :)
>
> Thanks.
>
> WBR,
> Alexey.
>
>
>