网络性能监测秘籍

网络性能监测秘籍

网络性能监测秘籍

关于应用程序性能管理有一个痛苦的事实那就是识别性能问题要比解决困难得多，所以本技术手册将重点为大家介绍监测网络性能的相关技巧，包括如何创建用于监控的网络性能基线，如何进行从存储到用户的应用程序性能监测，如何利用WIDS进行WLAN性能监测，如何使用iPerf测试工具进行无线网络性能的监测等，在技术手册的最后部分，还为大家推荐了几个优化网络性能的方法。

网络性能问题为何如此棘手

有关网络性能的抱怨声，对网络工程师来说应该是习以为常了，那么为何网络应用性能问题如此难以处理？糟糕的网络性能何时会影响应用？

网络应用性能问题为何如此棘手？

糟糕的网络性能何时会影响应用呢？

如何监测网络性能

本部分将重点介绍监测网络性能的相关技巧，包括如何创建用于监控的网络性能基线，如何进行从存储到用户的应用程序性能监测，如何利用WIDS进行WLAN性能监测，如何使用iPerf测试工具进行无线网络性能的监测等。

如何创建一个用于网络监控的网络性能基线

端到端网络应用程序性能监测

存储到用户的网络应用程序性能监管

如何利用WIDS进行WLAN性能监测?

使用测试工具iPerf监控无线网络性能

如何优化网络性能

跟踪和解决网络性能问题不是一件轻松的任务，要保证网络效率不仅要识别常常神秘莫测的网络瓶颈，而且需要非常理解你的机构的IT运营，以及当问题不可避免地出现时你的机构的承受能力。

制定内部用户SLA 解决网络性能问题 增加关联性解决网络性能管理问题

提高网络性能的十个技巧

网络应用性能问题为何如此棘手？

有关网络性能的抱怨声，对网络工程师来说应该是习以为常了，那么为何网络应用性

能问题如此难以处理？

关于网络管理，其中一个严重影响IT组织保证实现可接受的应用程序性能的问题

是，在大多数应用程序性能出现问题的例子中，往往首先发现性能问题的是最终用户，而

不是IT组织自己。而且，在最终用户告知IT组织后，IT组织仍然很难确定应用程序是否真的出现了问题，还是说这个性能问题实际上仍然在正常范围之内。

第二个明显的事实是，在大多数情况中，当应用程序性能开始降低时，人们往往会认

为网络出现了问题。这样就会有一个新的管理标准：“平均验证时间” (MTTI)。MTTI指

的是网络组织用于证明不是网络问题导致应用程序性能降低所需要的平均时间。在很多情

况下，一旦网络组织已经证明网络本身不存在问题时，那么其他一些IT组件（例如，服

务器）肯定是造成性能下降的原因。这种被动修复方法会延长解决问题的时间。

一个大型组织拥有数以百计的网络应用程序并不会让人感到意外。然而，这些应用程

序的业务重要性的差异却是非常大的。如果一个IT组织所使用的应用交付产品是平等地

对待每个应用程序，那么它是不可能取得成功的。例如，假设一个企业拥有300个网络应

用程序，并指派了一名网络工程师用一个月的时间来全面地了解一个典型应用程序，它所

生成的数据流类型，以及影响应用程序性能的因素。如果IT组织尝试对它的300个网络

应用程序进行全面的了解，那么它将需要25年。即使IT组织能够提供这些工作量，当他

们完成了应用程序的分析时，这些应用程序的特性也可能早已发生了变化，这样工程师们

所付出的努力也就没有多大价值了。

原文标题：网络应用性能问题为何如此棘手？

原文链接：/showcontent_47083.htm

(来源：TechTarget中国作者：Jim Metzler 译者：曾少宁陈柳)

糟糕的网络性能何时会影响应用呢？

问：最近，我的企业遇到了一些网络问题。事实上，我是一名Oracle DBA，但是，我对网络问题是如何影响我的应用感到越来越好奇。基本上，我每个星期都使用PING命令来检查网络是否正常。结果是，从客户端向DB服务上发送的数据包3.6%都会丢失。

我怎样才可以知道这个3.6%的值是否仍然可以接受的呢？是否这个值对某种类型的应用是坏的，而对其它的又是好的呢？

我实在不知道从何处着手，您能给我一个总体的思路或者一些我可以通过Google搜索来进行研究的因素吗？

最后，我想说的一点是我并不需要知道在何处以及为何网络性能是糟糕的，我想了解的是何时糟糕的网络性能会影响应用。

答：很高兴你提出这个问题。问得非常好！在各种不同的企业中，应用开发员用于确保他们应用性能良好的好方法之一就是了解应用调用是如何影响数据行为的。为了更好地说明，我称这种方法为Tarzan影响。大多数应用开发员都倾向于创建假定为无限制的本地网络访问的应用，同时是以单个而不是大量的请求来调用数据库/文件服务器。这就转化为网络工程师传统上所称的请求-响应应用。由于客户端要为每条信息等待整个网络的延迟，因此，数据库的每个请求会加剧网络延迟或者丢包；如果在最初的传输中就发生了丢失，那么影响是加倍的。如果Tarzan穿越整个丛林，它不会每次只摘下一个香蕉然后给大猩猩带回来，对吧？当然不是。它会制作一个篮子，然后一次外出就带回一篮子香蕉。它可以一次带回尽可能多的香蕉。然而，这里面也有一定的风险，因此需要一个改良的方法来了解它一次能从丛林中安全地带回多少香蕉。

如果Tarzan在丛林中摔跤了，并且弄丢了整个篮子的香蕉，那该怎么办？这里就是我们要解决的关于丢失的问题。如果数据包在网络上丢失了，那么基于TCP的连接会发生什么情况呢？我该如何重新找到这一篮子的水果呢？为了让问题简单点，我们假设我们并没有在网络优化上使用任何特定的机制，但是，如果我们意识到在延迟敏感和失真环境中我们需要它们的帮助，那么它们也是很值得研究的。首先，了解TCP事实上有一个TCP Slow Start的机制，它是一种用来了解环境是如何失真的方法，技术上称为拥塞避免和肯定应答。它通过在等待应的期间发送小增量的数据包到较大数据包的方式来缓慢地提升传输的窗口大小。（假定Tarzan开始是带2个香蕉给大猩猩，接着是4个，然后是8个，以此来了解到底它带多少香蕉给大猩猩是安全的。）如果在传输的过程中发生了传输丢失，那么下次传输的数据包数目就必须减半。TCP在检测到丢失时，就会在不需要得到应答的情况下减少数据包的数目。在因特网上有一些非常典型的锯齿图来阐明这个行为。