外文翻譯--網(wǎng)絡(luò)性能的測量

1、<p><b>　　中文2100字</b></p><p>　　英文翻譯：出自《Computer Network》第四版 Andrew S.Tanenbaum　著　</p><p>　　Network Performance Measurement</p><p>　　When a network performs poorly,

2、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 really happening, the operators must

3、make measurements. In this section we will look at network performance measurements. The discussion below is based on the work of Mogul (1993).</p><p>　　The basic loop used to improve network performance con

4、tains the following steps:</p><p>　　Measure the relevant network parameters and performance.</p><p>　　Try to understand what is going on.</p><p>　　Change one parameter.</p>&

5、lt;p>　　These steps are repeated until the performance is good enough or it is clear that the last drop of improvement has been squeezed out.</p><p>　　Measurements can be made in many ways and at many loca

6、tions (both physically and in the 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 TP

7、DU to be acknowledged is a key measurement. Other measurements are made with counters that record how often some event has happened (e.g., number of lost TPDUS). Finally, one is often interested in knowing the amount of

8、someth</p><p>　　Measuring network performance and parameters has many potential pitfalls. Below we list a few of them. Any systematic attempt to measure network performance should be careful to avoid these.&

9、lt;/p><p>　　Make Sure That the Sample Size Is Large Enough</p><p>　　Do not measure the time to send one TPDU, but repeat the measurement, say, one million times and take the average. Having a large

10、 sample will reduce the uncertainty in the measured mean and standard deviation. This uncertainty can be computed using standard statistical formulas.</p><p>　　Make Sure That the Samples Are Representative&l

11、t;/p><p>　　Ideally, 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 loads on the measured quantity. Measurement

12、s 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 o'clock,

13、but no congestion at noon (when all the users are away at lunch).</p><p>　　Be Careful When Using a Coarse-Grained Clock</p><p>　　Computer clocks work by incrementing some counter at regular inte

14、rvals. 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 some care. (Some computers have more accurate clocks,

15、 of course.)</p><p>　　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

16、true TPDU send time is 300 µsec, the difference between 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 di

17、vided by one million, the mean time will be accurate to better than 1 µsec.</p><p>　　Be Sure That Nothing Unexpected Is Going On during Your Tests</p><p>　　Making measurements on a universi

18、ty 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, y

19、ou may get a biased result. It is best to run tests 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., tha

20、t might be precisely when t</p><p>　　Caching Can Wreak Havoc with Measurements</p><p>　　The obvious way to measure file transfer times is to open a large file, read the whole thing, close it, an

21、d see how long it takes. Then repeat the measurement many more times to get a good average. The trouble is, the system may cache the file, so only the first measurement actually involves network traffic. The rest are jus

22、t reads from the local cache. The results from such a measurement are essentially worthless (unless you want to measure cache performance).</p><p>　　Often you can get around caching by simply overflowing the

23、 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

24、 you understand the caching algorithm.</p><p>　　Buffering can have a similar effect. One popular TCP/IP performance utility program has been known to report that UDP can achieve a performance substantially h

25、igher 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 kernel and added to the transmission queue. If there is sufficient buffer s

26、pace, timing 1000 UDP calls does not mean that all the data have been sent. Most of them may still be in the kernel, but </p><p>　　Understand What You Are Measuring</p><p>　　When you measure the

27、 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 measureme

28、nts are done carefully, you will ultimately discover the file transfer time for the configuration you are using. If your goal is to tune this particular configuration, these measurements are fine.</p><p>　　H

29、owever, 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 by the fact that one of the network drivers i

30、s truly awful and is only getting 10 percent of the performance of the board.</p><p><b>　　網(wǎng)絡(luò)性能的測量</b></p><p>　　當(dāng)一個網(wǎng)絡(luò)的運行效果很差的時候，它的用戶通常會向網(wǎng)絡(luò)運行商抱怨并要求提高網(wǎng)絡(luò)的質(zhì)量。為了改善網(wǎng)絡(luò)的性能，網(wǎng)絡(luò)操作人員首先必須確定發(fā)生了什么問題

31、。為了找出真正的問題所在，操作人員必須進(jìn)行測量工作。在這一小節(jié)中，我們來看一看網(wǎng)絡(luò)性能的測量問題。下面的討論以Mogul(1993)的工作為基礎(chǔ)。</p><p>　　用來改善網(wǎng)絡(luò)性能的基本循環(huán)過程包括以下步驟：</p><p>　　測量有關(guān)的網(wǎng)絡(luò)參數(shù)和性能。</p><p>　　試圖理解當(dāng)前的網(wǎng)絡(luò)狀況。</p><p><b>　

32、　改變一個參數(shù)。</b></p><p>　　這些步驟不斷重復(fù)，直到網(wǎng)絡(luò)的性能已經(jīng)足夠好，或者改善性能的全部空間都已經(jīng)被發(fā)掘出來了。</p><p>　　測量工作可以有許多做法，也可以在許多地點或場所進(jìn)行（既指物理位置，也指協(xié)議棧中的位置）。最基本的一種測量手段是：在開始某一個動作的時候啟動一個定時器，然后確定該需要多長時間。例如，知道一個TPDU需要多長時間才被確認(rèn)是一個很關(guān)

33、鍵的測量指標(biāo)。其他有一些測量指標(biāo)可以通過計數(shù)器來完成，即記錄某種事件發(fā)生的次數(shù)，比如丟失的TPDU的數(shù)量。最后，人們通常對于某些事物的數(shù)量比較感興趣，比如在特定的時間間隔內(nèi)所處理的字節(jié)數(shù)。</p><p>　　測量網(wǎng)絡(luò)的性能和參數(shù)有許多潛在的陷阱。以下我們列出其中一部分。任何一種系統(tǒng)化的網(wǎng)絡(luò)性能測量手段都應(yīng)該小心地避免這些陷阱。</p><p><b>　　確保樣本空間足夠大&l

34、t;/b></p><p>　　不要測量發(fā)送一個TPDU的時間，而是重復(fù)也測量。比如說測量1百萬次，然后再取平均。采用大量的樣本將可以減小所測量的均值和標(biāo)準(zhǔn)方差中的不確定性。這種不確定性可以利用標(biāo)準(zhǔn)的統(tǒng)計公式來計算。</p><p><b>　　確保樣本具有代表性</b></p><p>　　理想情況下，這1百萬次測量的完整序列應(yīng)該在一天

35、或者一周的不同時刻進(jìn)行重復(fù)，從而可以看到不同的系統(tǒng)負(fù)載對于所測量指標(biāo)的影響。例如，對于擁塞的測量，如果僅僅在沒有擁塞的那一時刻來測量擁塞，則這樣的測量和結(jié)果并沒有用。有時候測量結(jié)果初看起來可能不符合直覺，比如在10，11，1和2點鐘網(wǎng)絡(luò)嚴(yán)重?fù)砣?，但是中午時候沒有擁塞（所用的用戶都去吃午飯了）。</p><p>　　當(dāng)使用粗粒度時鐘的時候一定要謹(jǐn)慎</p><p>　　計算機(jī)時鐘的工作原理是

36、，每隔固定的時間間隔就遞增某一個計數(shù)器，例如，一個毫秒定時器每隔1ms就讓一個計數(shù)器加1。使用這樣的定時器來測量一個持續(xù)時間小于1ms的事件是有可能的，但要非常小心。（當(dāng)然，有些計算機(jī)還有更加精確的時鐘。）</p><p>　　例如，為了測量出發(fā)送一個TPDU所需要的時間，當(dāng)進(jìn)入傳輸層代碼時以及離開傳輸層代碼時，應(yīng)該將系統(tǒng)時鐘（比如說以毫秒為單位）讀出來。如果TPDU真正的發(fā)送時間是300µs,則兩次讀

37、取的時間之差要么是０，要么是１，這兩個結(jié)果都是錯誤的。然而，如果重復(fù)測量１百萬次，則所有測量的總和累加起來，再除以１百萬，則平均時間比１µs還要精確得多。</p><p>　　確保在測試過程中不會發(fā)生不可預(yù)知的事情</p><p>　　在一個大學(xué)的網(wǎng)絡(luò)系統(tǒng)進(jìn)行測量有可能發(fā)生這樣的情況：有一天，當(dāng)一個大型的實驗項目在運行的時候你測量的結(jié)果跟第二天測量出來的結(jié)果可能會有所不同。同樣地

38、，如果有的研究人員決定在你們的網(wǎng)絡(luò)上運行一個視頻會議，而在這個時候你正好在測量，那么你得到的結(jié)果可能會偏差。你最好在一個空閑的系統(tǒng)上運行測試過程，并且根據(jù)需要自己來創(chuàng)建所有的工作負(fù)載。不過這種做法也有缺陷。你可能認(rèn)為在凌晨3點鐘的時候不會有人使用網(wǎng)絡(luò)，但是，當(dāng)自動備份程序這時候開始將所有的磁盤數(shù)據(jù)復(fù)制到磁帶上的時候，你的想法就不再正確了。而且，此時其他時區(qū)的用戶可能會訪問你精美的WWW,從而也導(dǎo)致繁重的流量。</p>&l

39、t;p>　　緩存機(jī)制可能會破壞測量的正確性</p><p>　　為了測量文件傳輸時間，最顯然的方法是打開一個大的文件并讀取文件中所有的數(shù)據(jù)，再關(guān)閉文件，然后看這個過程花了多長時間。然后，多次重復(fù)這樣的測量過程以便得到一個好的平均值。然而，麻煩在于，系統(tǒng)可能會將文件緩存起來，所以，僅僅第一次測量才真正涉及到網(wǎng)絡(luò)傳輸，其他的測量只不過從本地的緩存中讀取數(shù)據(jù)而已。因此，這樣的測量結(jié)果本質(zhì)上是毫無價值的（除非你的目

40、標(biāo)是為了測量緩存機(jī)制的性能）。</p><p>　　通常你只要簡單地溢出緩存的方法就可以避免緩存帶來的問題。例如，如果緩存空間的大小為10MB，那么，測試循環(huán)可以輪流地打開、讀取和關(guān)閉兩個10MB文件，這樣做的目的是強迫緩存的命中率為0。不過。除非你絕對確定自己理解了緩存算法。否則仍然要非常小心。</p><p>　　緩沖機(jī)制也有類似的影響，一個流行的TCP/IP性能測試工具曾經(jīng)報告UDP

41、可以獲得比物理線路允許的能力還要好得多的性能。這是怎么發(fā)生的呢？在調(diào)用UDP的時候，通常當(dāng)內(nèi)核接受了消息之后，控制權(quán)馬上就返回給應(yīng)用程序了，而消息則被加入到傳輸隊列中。如果主機(jī)上有足夠的緩沖區(qū)空間的話，則執(zhí)行1000UDP調(diào)用并不意味著所有的數(shù)據(jù)都已經(jīng)被發(fā)送出去了，大多數(shù)數(shù)據(jù)仍然在內(nèi)核中，但是性能測試工具認(rèn)為是它們已經(jīng)被傳送出去了。</p><p><b>　　理解你的測試的指標(biāo)</b>&l

42、t;/p><p>　　當(dāng)你要測試讀取一個遠(yuǎn)程文件所需要的時間時，你的測量結(jié)果取決于以下諸多因素；網(wǎng)絡(luò)、客戶和服務(wù)器的操作系統(tǒng)、所使用的硬件接口卡、接口卡的驅(qū)動程序，等等。如果你謹(jǐn)慎地執(zhí)行了測量過程的話，那么，你最終得到的結(jié)果是在你所使用的配置環(huán)境中的文件傳輸時間。如果你的目標(biāo)是要調(diào)整這一特殊的配置環(huán)境，那么這些測量結(jié)果將是非常有用的。</p><p>　　然而，如果你在三個不同的網(wǎng)絡(luò)系統(tǒng)上進(jìn)行