Versi garis besar: Aplikasi berkinerja sangat buruk

  • Artikel

Sampel kode berkinerja buruk awal yang digunakan untuk menghitung pembaruan adalah sebagai berikut:

Catatan

Untuk kesederhanaan, tidak ada penanganan kesalahan dalam contoh berikut. Aplikasi produksi apa pun selalu memeriksa nilai pengembalian.

 

Peringatan

Beberapa contoh pertama aplikasi memberikan performa yang sengaja buruk, untuk menggambarkan peningkatan performa yang mungkin terjadi dengan perubahan pada kode. Jangan gunakan sampel kode ini di aplikasi Anda; mereka hanya untuk tujuan ilustrasi.

 

#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;
}

Dalam keadaan ini, aplikasi memiliki performa jaringan terburuk yang mungkin. Masalah dengan versi aplikasi sampel ini meliputi:

  • Aplikasi ini cerewet. Setiap transaksi terlalu kecil — sel tidak perlu diperbarui satu per satu.
  • Transaksi diserialisasikan secara ketat, meskipun sel dapat diperbarui secara bersamaan.
  • Buffer kirim diatur ke nol, dan aplikasi menimbulkan penundaan 200 milidetik untuk setiap pengiriman — tiga kali per sel.
  • Aplikasi ini sangat terhubung berat, menghubungkan sekali untuk setiap sel. Aplikasi dibatasi dalam jumlah koneksi per detik untuk tujuan tertentu karena status TIME-WAIT, tetapi itu bukan masalah di sini, karena setiap transaksi membutuhkan lebih dari 600 milidetik.
  • Aplikasi ini gemuk; banyak transaksi tidak berpengaruh pada status server, karena banyak sel tidak berubah dari pembaruan ke pembaruan.
  • Aplikasi ini menunjukkan streaming yang buruk; pengiriman kecil mengonsumsi banyak CPU dan RAM.
  • Aplikasi ini mengasumsikan representasi little-endian untuk pengirimannya. Ini adalah asumsi alami untuk platform Windows saat ini, tetapi bisa berbahaya untuk kode berumur panjang.

Metrik Performa Utama

Metrik performa berikut dinyatakan dalam Round Trip Time (RTT), Goodput, dan Protocol Overhead. Lihat topik Terminologi Jaringan untuk penjelasan tentang istilah-istilah ini.

  • Waktu sel, waktu jaringan untuk pembaruan sel tunggal, memerlukan 4*RTT + 600 milidetik untuk Nagle dan interaksi ACK yang tertunda.
  • Goodput kurang dari 6 byte.
  • Overhead Protokol adalah 99,6%.

Meningkatkan Aplikasi Lambat

Terminologi Jaringan

Revisi 1: Membersihkan yang Jelas

Revisi 2: Mendesain Ulang untuk Lebih Sedikit Koneksi

Revisi 3: Blok Terkompresi Kirim

Penyempurnaan Di Masa Depan