Hi Dan,
On 10.04.15 16:36, Daniel Feist wrote:
>
> Just wondering what the optimal configuration for a HTTP proxy is:
>
> i) Use SameThreadIOStrategy for inbound and outbound. This one I'm
> clear on.
Ok.
> ii) Is using the same Grizzly Transport instance important or
> significant? I assume not.
Well, IMO it's definitely worth investigating, this way you can optimize
threads and selectors consumption, but I can't guarantee it will
outperform two transports approach for all cases.
> iii) If not using the same transport, is using the same selector
> threadPool for both inbound and outbound grizzly transports
> beneficial, important or makes no difference.?
IMO not, I doubt it will give you anything, AFAIR every Transport
creates its own selector threads using the selector thread pool, so if
two transports share one selector thread pool - they would still create
as many threads as if it were 2 different thread pools.
> (Using AHC for outbound means sharing the Transport instance isn't
> really an option, but sharing the same selector threadPool could be an
> option.)
Right, I think existing AHC implementation doesn't support transport
sharing, but it's all doable (if needed).
> A couple of other comments/questions:
>
> - When using AHC it would appear that even if both inbound/outbound
> are using the same selector pool, a thread handover will still occur
> because AHC obtains the outbound connection asynchronsouly using the
> outbound selector threadPool and then sends the request using that
> same thread. This right?
If there is a connection in the connection pool - AHC will obtain it in
the same thread, but if there is no connection - then yes it will
probably obtain it asynchronously.
> - 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.
>
> Once I complete my changes I'll have:
>
> *request*: Client -> Inbound Selector -> (Optional Worker X) ->
> Outbound Selector - > Target Service
> *response:* Target Service -> Outbound Selector -> (Optional Worker X)
> -> Inound Selector - Client.
The "write" Selector (it's Outbound for the request and Inbound for the
response) will not be involved if the write operation can be completed
right away without blocking (without tcp output buffer overflow), so
normally you won't have any thread context switches. And it doesn't
matter if you share or not the same Transport instance.
Thanks.
WBR,
Alexey.
>
> (Note: the optional workers woud come from the same Exectuor)
>
> Make sense? Or should I ideally be looking to by using 1 thread each
> way rather than the minimum two I'd have with default AHC/Grizzly
> behaviuor observed and describied above.
>
> Dan