[c-nsp] Application Protocol Performance in low latency envrionments

[Ash Net]

Thanks Guys. Your feedback is greatly appreciated.

On 8/26/09, Tim Durack <tdurack at gmail.com> wrote:
> On Wed, Aug 26, 2009 at 6:23 AM, Mikael Abrahamsson
> <swmike at swm.pp.se>wrote:
>
>> On Wed, 26 Aug 2009, Ash Net wrote:
>>
>>  The reason for performance degradation solely seems to be latency
>> related
>>> since there's tons of b/w available in the lab setup and over 10G lanphy
>>> paths. Do people still deploy QOS for better traffic management on the
>>> lanphy interfaces even with no saturation?.
>>>
>>
>> All the protocols you mentioned are "query/response" ones and thus they
>> take a big hit when latency is introduced.
>>
>> I know several companies who nowadays has a wan simulation device between
>> the clients and servers in their dev labs, just so that the developers
>> will
>> develop applications that actually work in real life, not just in the
>> 1/10
>> ms latency of the dev environment. Imagine the difference in a latency
>> environment between doing a single nested SQL query, as opposed to doing
>> 1
>> returning a list, and then doing one query per list entry. In a 1/10ms
>> environment the difference might not be noticeable, but in a 100ms
>> environment it most certainly will.
>>
>> At several ms network latency you're effectively dealing with harddrive
>> latencies as opposed to almost memory latencies, and thus techniques that
>> work akin to NCQ or alike needs to be employed. Failure to do so will
>> create
>> performance problems in real life.
>>
>>
> Serious feelings of deja-vu. We lived through a similar scenario over the
> last few months. GigE "WAN" (really a MAN) with 3-5ms latency. Had to
> install some WAN accelerators, 'cos they promise to fix everything. WAN
> Accelerators don't work in this scenario for the reason Mikael mentions
> (the
> IO subsystem of a WAN accelerator is in the 2-3ms range.)
>
> Only real answer is to get application developers to code for the Internet
> at large, rather than for <1ms LAN. Of course our devs don't even like
> their
> dev servers being 3-5ms away...
>
> Tim:>
>