Thanks Guys. Your feedback is greatly appreciated.
On 8/26/09, Tim Durack <[email protected]> wrote: > On Wed, Aug 26, 2009 at 6:23 AM, Mikael Abrahamsson > <[email protected]>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:> > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
