基準版本：效能不佳的應用程式
用來計算更新的初始效能不佳程式碼範例如下所示：
注意
為了簡單起見，下列範例中沒有錯誤處理。 任何生產應用程式一律會檢查傳回值。
警告
應用程式的前幾個範例提供刻意不佳的效能，以說明程式碼變更可能改善的效能。 請勿在應用程式中使用這些程式碼範例;它們僅供說明之用。
#include <windows.h>
BOOL Map[ROWS][COLS];
void LifeUpdate()
{
ComputeNext( Map );
for( int i = 0 ; i < ROWS ; ++i ) //serialized
for( int j = 0 ; j < COLS ; ++j )
Set( i, j, Map[i][j] ); //chatty
}
BYTE Set(row, col, bAlive)
{
SOCKET s = socket(...);
BYTE byRet = 0;
setsockopt( s, SO_SNDBUF, &Zero, sizeof(int) );
bind( s, ... );
connect( s, ... );
send( s, &row, 1 );
send( s, &col, 1 );
send( s, &bAlive, 1 );
recv( s, &byRet, 1 );
closesocket( s );
return byRet;
}
在此狀態中，應用程式具有最差的網路效能。 此版本的範例應用程式的問題包括：
- 應用程式很閒聊。 每個交易太小 ， 儲存格不需要逐一更新。
- 交易會嚴格序列化，即使可以同時更新儲存格也一樣。
- 傳送緩衝區會設定為零，而應用程式會針對每個傳送產生 200 毫秒的延遲，每個儲存格有三次。
- 應用程式很繁重，每個資料格都會連接一次。 應用程式會因為 TIME-WAIT 狀態而限制特定目的地每秒的連線數目，但這不是這裡的問題，因為每個交易會佔用超過 600 毫秒。
- 應用程式很豐富;許多交易不會影響伺服器狀態，因為許多儲存格不會從更新變更為更新。
- 應用程式呈現不佳的串流;小型傳送會耗用大量 CPU 和 RAM。
- 應用程式會假設其傳送的端端標記法。 這是目前 Windows 平臺的自然假設，但對於長期程式碼而言可能很危險。
關鍵效能計量
下列效能計量會以 RTT) 、Goodput 和通訊協定額外負荷 (來表示。 如需這些詞彙的說明，請參閱 網路術語 主題。
- 資料格時間，單一儲存格更新的網路時間，Nagle 和延遲的 ACK 互動需要 4*RTT + 600 毫秒。
- Goodput 小於 6 個位元組。
- 通訊協定額外負荷為 99.6%。
相關主題