如果您的公司与大多数公司一样，那么远程用户是否抱怨系统并不重要，重要的是他们在什么时候向您抱怨。而且，如果系统需要通过广域网(WAN)访问主要位置的资源，那么WAN就是可能就是问题所在。
虽然有很多方法可以评估WAN性能，但是测试WAN延迟时间(流量通过WAN时所需要时间)是一个很好的出发点。简单而言，延迟时间会增加用户的等待时间。再加上其他系统原因的延迟(如数据库访问)，WAN延迟时间的激增可能意味着损失用户或者操作中断。
虽然延迟各不同相同，但是许多北美网络的回程时间一般在35至70毫秒(ms)之间——或者说小于十分之一秒。如果延迟突然增加到1,500ms，那么用户就需要经历额外的一秒钟来等待WAN。
当帮助中心接到关于性能问题的呼叫，您需要以下两点去处理问题：
– 测试当前WAN延迟时间
– 供当前延迟测试参照的“晴天”WAN延迟测试基线
好消息是，如果您现在遇到了WAN问题，那么测试当前的WAN延迟时间是很快的。坏消息是，您无法回到未测试延迟时的网络无故障时间。所以，在WAN当前运行良好时，要记录这些“晴天”数据，这样您才能够对最坏的情况做出基础评估。
为了测试WAN延迟时间，您只需要使用简单且使用广泛的免费网络工具Ping。Ping支持在各种平台上实施TCP/IP，所以无论您使用的是Windows、Apple OS X或者是Linux，都能够使用Ping工具。
当然，要测试WAN延迟时间，您需要Ping两个WAN路由器之间的链路;因此，在终端设备中使用Ping命令是最有效的方法。默认情况下，大多数路由器都会响应Ping，所以从当前计算机Ping远程路由器最起码能够了解大概的WAN延迟时间。
类似地，大多数路由器都在它们的控制台中使用Ping命令。所以，人们可以用Telnet连接到一台路由器控制台，然后Ping远端路由器，这样就能够测试两台设备之间链路的延迟时间。
不同的Ping命令很可能有所差别，但是大多数情况都默认会发送4、5个echo请求，然后报告各个请求的平均回程WAN延迟时间与丢包情况。实际上，Ping使用了互联网消息控制协议(IMCP)的“Echo”命令触发目标IP系统响应，以此获得最终的测试数据。
如果每一次echo的丢包或延迟时间都有明显变化，如抖动，那么就意味着需要更多的调查。
Ping可以配置发送数据包大小和运行次数;它还可以持续运行。大多数操作系统都支持定期自动执行Ping，然后将结果保存在日志文件以备将来使用。
然而，一定要清楚，执行Ping会给网络及响应的设备网络带来一些负载。虽然使用一般默认设置运行Ping产生的负载很小，但是最好不要无故使用Ping。
因为事实上，Ping可能造成分布式拒绝服务攻击(DDoS)。一台受Ping请求阻塞的设备会将所有处理时间耗在echo响应处理上，而非正常的生产数据。因此，网络设备有用的吞吐量会下降。对于用户而言，他们会认为网络响应时间出现问题。因此，许多大型网络都特意在它们的路由器上禁用echo响应功能，以避免受到基于Ping的DDos攻击。
最后，如果您的WAN负载过多，那么就应该升级带宽。否则，如果它同时传输低优先级、大容量和时间敏感的VoIP及交互流量，那么可能就需要专门的WAN带宽优化解决方案来执行排队和流量管理。无论何种情况，首先是要理解您的WAN负载——为此，您必须知道如何测试WAN延迟时间。
