外文翻译--网络性能的测量

《外文翻译--网络性能的测量》由会员分享，可在线阅读，更多相关《外文翻译--网络性能的测量（6页珍藏版）》请在装配图网上搜索。

1、中文2100字英文翻译：出自Computer Network第四版 Andrew S.Tanenbaum 著Network Performance MeasurementWhen a network performs poorly, its users often complain to the folks running it, demanding improvements. To improve the performance, the operators must first determine exactly what is going on. To find out what is

2、really happening, the operators must make measurements. In this section we will look at network performance measurements. The discussion below is based on the work of Mogul (1993).The basic loop used to improve network performance contains the following steps:1. Measure the relevant network paramete

3、rs and performance.2. Try to understand what is going on.3. Change one parameter.These steps are repeated until the performance is good enough or it is clear that the last drop of improvement has been squeezed out.Measurements can be made in many ways and at many locations (both physically and in th

4、e protocol stack). The most basic kind of measurement is to start a timer when beginning some activity and see how long that activity takes. For example, knowing how long it takes for a TPDU to be acknowledged is a key measurement. Other measurements are made with counters that record how often some

5、 event has happened (e.g., number of lost TPDUS). Finally, one is often interested in knowing the amount of something, such as the number of bytes processed in a certain time interval.Measuring network performance and parameters has many potential pitfalls. Below we list a few of them. Any systemati

6、c attempt to measure network performance should be careful to avoid these.Make Sure That the Sample Size Is Large EnoughDo not measure the time to send one TPDU, but repeat the measurement, say, one million times and take the average. Having a large sample will reduce the uncertainty in the measured

7、 mean and standard deviation. This uncertainty can be computed using standard statistical formulas.Make Sure That the Samples Are RepresentativeIdeally, the whole sequence of one million measurements should be repeated at different times of the day and the week to see the effect of different system

8、loads on the measured quantity. Measurements of congestion, for example, are of little use if they are made at a moment when there is no congestion. Sometimes the results may be counterintuitive at first, such as heavy congestion at 10, 11, 1, and 2 oclock, but no congestion at noon (when all the us

9、ers are away at lunch).Be CarefUl When Using a Coarse-Grained ClockComputer clocks work by incrementing some counter at regular intervals. For example, a millisecond timer adds 1 to a counter every 1 msec. Using such a timer to measure an event that takes less than 1 msec is possible, but requires s

10、ome care. (Some computers have more accurate clocks, of course.)To measure the time to send a TPDU, for example, the system clock (say, in milliseconds) should be read out when the transport layer code is entered and again when it is exited. If the true TPDU send time is 300 psec, the difference bet

11、ween the two readings will be either 0 or 1, both wrong. However, if the measurement is repeated one million times and the total of all measurements added up and divided by one million, the mean time will be accurate to better than 1 psec.Be Sure That Nothing Unexpected Is Going On during Your Tests

12、Making measurements on a university system the day some major lab project has to be turned in may give different results than if made the next day. Likewise, if some researcher has decided to run a video conference over your network during your tests, you may get a biased result. It is best to run t

13、ests on an idle system and create the entire workload yourself. Even this approach has pitfalls though. While you might think nobody will be using the network at 3 A.M., that might be precisely when the automatic backup program begins copying all the disks to tape. Furthermore, there might be heavy

14、traffic for your wonderful World Wide Web pages from distant time zones.Caching Can Wreak Havoc with MeasurementsThe obvious way to measure file transfer times is to open a large file, read the whole thing, close it, and see how long it takes. Then repeat the measurement many more times to get a goo

15、d average. The trouble is, the system may cache the file, so only the first measurement actually involves network traffic. The rest are just reads from the local cache. The results from such a measurement are essentially worthless (unless you want to measure cache performance).Often you can get arou

16、nd caching by simply overflowing the cache. For example, if the cache is 10 MB, the test loop could open, read, and close two 10-MB files on each pass, in an attempt to force the cache hit rate to 0. Still, caution is advised unless you are absolutely sure you understand the caching algorithm.Buffer

17、ing can have a similar effect. One popular TCP/IP performance utility program has been known to report that UDP can achieve a performance substantially higher than the physical line allows. How does this occur? A call to UDP normally returns control as soon as the message has been accepted by the ke

18、rnel and added to the transmission queue. If there is sufficient buffer space, timing 1000 UDP calls does not mean that all the data have been sent. Most of them may still be in the kernel, but the performance utility thinks they have all been transmitted.Understand What You Are MeasuringWhen you me

19、asure the time to read a remote file, your measurements depend on the network, the operating systems on both the client and server, the particular hardware interface boards used, their drivers, and other factors. If the measurements are done carefully, you will ultimately discover the file transfer

20、time for the configuration you are using. If your goal is to tune this particular configuration, these measurements are fine.However, if you are making similar measurements on three different systems in order to choose which network interface board to buy, your results could be thrown off completely

21、 by the fact that one of the network drivers is truly awful and is only getting 10 percent of the performance of the board.网络性能的测量当一个网络的运行效果很差的时候，它的用户通常会向网络运行商抱怨并要 求提高网络的质量。为了改善网络的性能，网络操作人员首先必须确定发生了什 么问题。为了找出真正的问题所在，操作人员必须进行测量工作。在这一小节中， 我们来看一看网络性能的测量问题。下面的讨论以Mogul（1993）的工作为基础。用来改善网络性能的基本循环过程包括以下步骤：（

22、1）测量有关的网络参数和性能。（2）试图理解当前的网络状况。（3）改变一个参数。这些步骤不断重复，直到网络的性能已经足够好，或者改善性能的全部空间 都已经被发掘出来了。测量工作可以有许多做法，也可以在许多地点或场所进行（既指物理位置， 也指协议栈中的位置）。最基本的一种测量手段是：在开始某一个动作的时候启 动一个定时器，然后确定该需要多长时间。例如，知道一个TPDU需要多长时间 才被确认是一个很关键的测量指标。其他有一些测量指标可以通过计数器来完 成，即记录某种事件发生的次数，比如丢失的TPDU的数量。最后，人们通常对 于某些事物的数量比较感兴趣，比如在特定的时间间隔内所处理的字节数。测量网络

23、的性能和参数有许多潜在的陷阱。以下我们列出其中一部分。任何 一种系统化的网络性能测量手段都应该小心地避免这些陷阱。确保样本空间足够大不要测量发送一个TPDU的时间，而是重复也测量。比如说测量1百万次， 然后再取平均。采用大量的样本将可以减小所测量的均值和标准方差中的不确定 性。这种不确定性可以利用标准的统计公式来计算。确保样本具有代表性理想情况下，这1百万次测量的完整序列应该在一天或者一周的不同时刻进 行重复，从而可以看到不同的系统负载对于所测量指标的影响。例如，对于拥塞 的测量，如果仅仅在没有拥塞的那一时刻来测量拥塞，则这样的测量和结果并没 有用。有时候测量结果初看起来可能不符合直觉，比如在

24、10，11，1和2点钟网 络严重拥塞，但是中午时候没有拥塞（所用的用户都去吃午饭了）。当使用粗粒度时钟的时候一定要谨慎计算机时钟的工作原理是，每隔固定的时间间隔就递增某一个计数器，例如， 一个毫秒定时器每隔1ms就让一个计数器加1。使用这样的定时器来测量一个持 续时间小于1ms的事件是有可能的，但要非常小心。（当然，有些计算机还有更 加精确的时钟。）例如，为了测量出发送一个TPDU所需要的时间，当进入传输层代码时以及 离开传输层代码时，应该将系统时钟（比如说以毫秒为单位）读出来。如果TPDU 真正的发送时间是300心,则两次读取的时间之差要么是0,要么是1,这两个 结果都是错误的。然而，如果重

25、复测量1百万次，则所有测量的总和累加起来， 再除以1百万，则平均时间比1火还要精确得多。确保在测试过程中不会发生不可预知的事情在一个大学的网络系统进行测量有可能发生这样的情况：有一天，当一个大 型的实验项目在运行的时候你测量的结果跟第二天测量出来的结果可能会有所 不同。同样地，如果有的研究人员决定在你们的网络上运行一个视频会议，而在 这个时候你正好在测量，那么你得到的结果可能会偏差。你最好在一个空闲的系 统上运行测试过程，并且根据需要自己来创建所有的工作负载。不过这种做法也 有缺陷。你可能认为在凌晨3点钟的时候不会有人使用网络，但是，当自动备份 程序这时候开始将所有的磁盘数据复制到磁带上的时候

26、，你的想法就不再正确 了。而且，此时其他时区的用户可能会访问你精美的WWW,从而也导致繁重的流 量。缓存机制可能会破坏测量的正确性为了测量文件传输时间，最显然的方法是打开一个大的文件并读取文件中所 有的数据，再关闭文件，然后看这个过程花了多长时间。然后，多次重复这样的 测量过程以便得到一个好的平均值。然而，麻烦在于，系统可能会将文件缓存起 来，所以，仅仅第一次测量才真正涉及到网络传输，其他的测量只不过从本地的 缓存中读取数据而已。因此，这样的测量结果本质上是毫无价值的（除非你的目 标是为了测量缓存机制的性能）。通常你只要简单地溢出缓存的方法就可以避免缓存带来的问题。例如，如果 缓存空间的大小为

27、10MB,那么，测试循环可以轮流地打开、读取和关闭两个10MB 文件，这样做的目的是强迫缓存的命中率为0。不过。除非你绝对确定自己理解 了缓存算法。否则仍然要非常小心。缓冲机制也有类似的影响，一个流行的TCP/IP性能测试工具曾经报告UDP 可以获得比物理线路允许的能力还要好得多的性能。这是怎么发生的呢？在调用 UDP的时候，通常当内核接受了消息之后，控制权马上就返回给应用程序了，而 消息则被加入到传输队列中。如果主机上有足够的缓冲区空间的话，则执行 1000UDP调用并不意味着所有的数据都已经被发送出去了，大多数数据仍然在内 核中，但是性能测试工具认为是它们已经被传送出去了。理解你的测试的指标当你要测试读取一个远程文件所需要的时间时，你的测量结果取决于以下诸 多因素；网络、客户和服务器的操作系统、所使用的硬件接口卡、接口卡的驱动 程序，等等。如果你谨慎地执行了测量过程的话，那么，你最终得到的结果是在 你所使用的配置环境中的文件传输时间。如果你的目标是要调整这一特殊的配置 环境，那么这些测量结果将是非常有用的。然而，如果你在三个不同的网络系统上进行类似的测量以便决定应该选购哪 一块接口卡，那么你的结果可能完全不具备参考价值，因为其中一个网络驱动非 常糟糕，它只能发挥接口卡的10%性能。