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

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ò)性能的測(cè)量</b></p><p>　　當(dāng)一個(gè)網(wǎng)絡(luò)的運(yùn)行效果很差的時(shí)候，它的用戶通常會(huì)向網(wǎng)絡(luò)運(yùn)行商抱怨并要求提高網(wǎng)絡(luò)的質(zhì)量。為了改善網(wǎng)絡(luò)的性能，網(wǎng)絡(luò)操作人員首先必須確定發(fā)生了什么問(wèn)題

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

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

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

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

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

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

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

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

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

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

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

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