应用性能问题和延迟

在试图解决应用性能问题时，通常对通信层延迟的影响估计不足，但如果你要引导你的努力朝向实际的解决方案，正确的理解是至关重要的。

首先，我所说的通信层延迟是指一个数据包从本地系统到远程系统再回到本地系统所需要的时间。通信层延迟的最大因素是距离--至少对于地理上相隔的主机来说是这样。另一个主要因素是本地和远程主机之间处理数据包的设备数量；这包括路由器和防火墙等。链路的带宽起着一定的作用，但没有大多数人想象的那么大。带宽会影响插入延迟--把一个数据包放在电线上需要多长时间，但电线上的信号以基于介质而不是带宽的速度传播。在接下来的讨论中，当我指的是通信层延迟时，我将只使用延迟。

为了演示延迟如何影响你的应用程序，让我们假设你在客户端应用程序中输入一些数据并按下回车键。客户端应用程序发送一条消息到服务器应用程序，等待响应，然后再发送另一条消息，等待响应，等等；进行N个回合。在N个回合结束时，客户端应用程序将结果返回给你。

假设需要10个回合，服务器应用程序需要1ms的时间来处理客户端消息并发回一个答案。在延迟为1ms的情况下，你得到的响应时间为10*（1ms+1ms）或20ms。现在坐上飞机去芝加哥，服务器停留在波士顿，所以你现在的延迟比如说50ms，响应时间为10*（50ms+1ms）或550ms。这足以让人注意到，但不会让人痛苦。将匝数增加到100，你现在有一个痛苦的5.5秒的响应时间。你可能会认为100个回合是过度的，但一些复杂的数据库查询或填写复杂表格的应用程序可以做到这一点。你知道你的应用程序需要多少个回合吗？
通过OSL做一个copy_file也会表现出这种行为。OSL会以4K的事务发送文件。每个事务都需要一个响应，所以一个1,000,000字节的文件将需要1,000,000 / 4,096 = 245个事务，或者使用前一段的命名法。同样，假设处理事务的时间为1ms，延迟为1ms，那么copy_file将需要490ms。如果我们把延迟增加到50ms，将需要12.495秒。如果我们将文件增加到1,000,000,000字节，则需要244,141个事务；1ms延迟的相应时间为488.282秒，50ms延迟的相应时间为12,451.191秒，差不多3.5小时。

衡量延迟的最简单方法是用ping。

你也可以使用我写的一个程序，在不需要使用packet_monitor的情况下对连接进行计时。参见http://members.cox.net/ndav1/self_published/stcp_tping.doc。stcp_tping命令需要你连接到远程主机的一个活动端口。在本例中，我使用的是23号端口(telnet)，但任何活动端口都可以使用。命令末尾的数字1表示每秒钟发送一次请求。