Re: Increasing row retrieving speed via net8 - SOLVED
From: GG <grzegorzof_at_interia.pl>
Date: Tue, 17 Apr 2012 17:39:01 +0200
Message-ID: <4F8D8E95.3080906_at_interia.pl>
W dniu 2012-04-16 20:13, Tanel Poder pisze:
> And if you're wondering, how come it's possible that 10 x application
> connections can retrieve 10 x more than a single application
> connection - this is why I listed the Bandwidth Delay Product as #2 in
> the list. If you have too small TCP buffer sizes for your network
> latency (delay) and link max theoretical throughput (bandwidth) then
> this buffer size ends up throttling your TCP connection throughput.
> The reason - TCP is a reliable protocol, thus a TCP packet can not be
> discarded from the TCP send buffer before an ACK has arrived for at
> least that packet sequence number (or higher). So, the higher the
> network latency (time to get ACK) and the lower the TCP buffer size,
> the lower your connection's throughput will be throttled to.
>
> With 10 x connections however, each connection have their own TCP
> send/receive buffers, thus the aggregate throughput for all the
> connections is 10 x higher.
Well , it was about buffers but not tcp at least not in that moment :). Informatica got its own buffers:
*DTM Buffer Cache and DTM Buffer Block size and default values are not optimal for large (270 columns) row sources. Looks like with that buffers You can scale fetch size and with 200MB buffer I was having 400k fetch size :) . Now I can saturated 100Mbit with 1 connection :) So now its time to play with tcp/ip stack / sdu buffers when we finished with application .
Still dont know how strace looks like now , probably get root tomorrow :). Regards
GregG
Date: Tue, 17 Apr 2012 17:39:01 +0200
Message-ID: <4F8D8E95.3080906_at_interia.pl>
W dniu 2012-04-16 20:13, Tanel Poder pisze:
> And if you're wondering, how come it's possible that 10 x application
> connections can retrieve 10 x more than a single application
> connection - this is why I listed the Bandwidth Delay Product as #2 in
> the list. If you have too small TCP buffer sizes for your network
> latency (delay) and link max theoretical throughput (bandwidth) then
> this buffer size ends up throttling your TCP connection throughput.
> The reason - TCP is a reliable protocol, thus a TCP packet can not be
> discarded from the TCP send buffer before an ACK has arrived for at
> least that packet sequence number (or higher). So, the higher the
> network latency (time to get ACK) and the lower the TCP buffer size,
> the lower your connection's throughput will be throttled to.
>
> With 10 x connections however, each connection have their own TCP
> send/receive buffers, thus the aggregate throughput for all the
> connections is 10 x higher.
Well , it was about buffers but not tcp at least not in that moment :). Informatica got its own buffers:
*DTM Buffer Cache and DTM Buffer Block size and default values are not optimal for large (270 columns) row sources. Looks like with that buffers You can scale fetch size and with 200MB buffer I was having 400k fetch size :) . Now I can saturated 100Mbit with 1 connection :) So now its time to play with tcp/ip stack / sdu buffers when we finished with application .
Still dont know how strace looks like now , probably get root tomorrow :). Regards
GregG
*
-- http://www.freelists.org/webpage/oracle-lReceived on Tue Apr 17 2012 - 10:39:01 CDT