Very interesting. My previuos tests had been with a simple inbound echo.
When testing with a non-blocking proxy (1Kb payload, 5ms target service
latency) optimizedForMultiplexing=false appears to give better TPS and
latency :-)
Having some issues with non-blocking proxy in general though, getting
decent number of errors whereas in blocking mode get zero. Is it possible
that stale connections aren't handled in the same way, or is there
something else that might be causing this? I'll do some more digging
around, but what I'm seeing right now is 0.05% of jmeter client requests
timing out after 60s.
Dan
On Tue, Apr 14, 2015 at 9:25 PM, Oleksiy Stashok <oleksiy.stashok_at_oracle.com
> wrote:
> Hi Dan,
>
> yeah, there is no silver bullet solution for all kind of usecases.
> An optimizedForMultiplexing is useful for concurrent writes, because the
> outbound messages are always added to the queue and written from the
> selector/nio thread, and at the write time Grizzly packs all (up to some
> limit) the available outbound messages and send them as one chunk, which
> reduces number of I/O operations. When optimizedForMultiplexing is
> disabled (by default) Grizzly (if the output queue is empty) first tries to
> send the outbound message right away in the same thread.
> So I'd say when optimizedForMultiplexing is disabled we potentially
> reduce latency, when optimizedForMultiplexing is enabled we increase
> throughput. But it's very simple way to look at this config parameter, I
> bet on practice you can experience opposite :))
>
> Thanks.
>
> WBR,
> Alexey.
>
>
> On 13.04.15 23:40, Daniel Feist wrote:
>
> 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.
>>
>>
>>
>
>