Hitung laju transfer berguna yang dibutuhkan jendela pengiriman Anda, lalu ukur jalur lengkapnya. Kapasitas port, round-trip time, perilaku TCP, penyimpanan dan pemrosesan aplikasi semuanya memengaruhi hasil. Gunakan pengujian terkendali dengan konkurensi yang realistis dan ulangi melalui aplikasi yang sebenarnya sebelum memilih tier jaringan.
Ubah jendela pengiriman menjadi laju
Mulailah dengan jumlah data aplikasi yang berguna dan waktu yang tersedia untuk mengirimkannya. Dengan satuan desimal, mentransfer 2 TB dalam dua jam memerlukan sekitar 278 MB per detik payload, atau 2.22 Gbps, sebelum memperhitungkan overhead protokol dan gangguan. Aritmetika ini adalah contoh perencanaan, bukan hasil layanan yang terukur.
Sertakan transfer yang tumpang tindih. Ekspor terjadwal, unduhan pelanggan dan unggahan cadangan dapat berbagi sumber daya meskipun total bulanannya terlihat moderat. Tulis model periode sibuk, bukan hanya rata-rata bulanan. Tentukan arah mana yang penting dan apakah transfer yang gagal harus dimulai ulang atau dapat dilanjutkan; perilaku itu memengaruhi jumlah pekerjaan yang dilakukan sistem.
Pisahkan kapasitas port dari throughput yang berguna
Port server menggambarkan kapasitas tautan. Throughput yang berguna menggambarkan data yang dikirim oleh aplikasi Anda selama interval yang diamati. Enkripsi, framing protokol, transmisi ulang, aktivitas penyimpanan dan pekerjaan di penerima menempati sebagian jalur tersebut. Port 10 Gbps yang tercantum karena itu tidak membuktikan bahwa aplikasi akan terus-menerus mengirimkan 10 Gbps payload.
IETF RFC 6349 secara khusus membedakan pengujian jalur jaringan dari pemeriksaan kinerja TCP. Gunakan pemisahan ini dalam diagnosis Anda sendiri. Pertama konfirmasi bahwa endpoint dan rute sudah sesuai, lalu selidiki transport dan aplikasi. Meningkatkan port yang dibeli tidak memperbaiki penerima yang menulis data dengan lambat atau aplikasi yang memproses satu permintaan pada satu waktu.
Pahami mengapa round-trip time penting
TCP mengontrol berapa banyak data yang dapat tetap dalam perjalanan sebelum acknowledgement kembali. Bandwidth-delay product memberikan skala yang berguna untuk ini: laju dikalikan round-trip time. Jalur 10 Gbps hipotetis dengan 40 milidetik penundaan round-trip mewakili sekitar 50 MB dalam perjalanan. Perhitungan ini menjelaskan mengapa latensi dan perilaku transport termasuk dalam perencanaan kecepatan tinggi.
Hasilnya bukan instruksi untuk menerapkan pengaturan soket yang arbitrer. Sistem operasi, kontrol kongesti, jendela yang dinegosiasikan dan jalur sebenarnya memengaruhi perilaku. Verifikasi dokumentasi perangkat lunak terkini dan periksa pengukuran sebelum melakukan penyetelan. Lebih banyak koneksi paralel dapat meningkatkan throughput agregat dalam beberapa keadaan, tetapi juga dapat menyembunyikan perilaku transfer individual yang menjadi sandaran aplikasi Anda.
Bangun matriks pengujian terkendali
Gunakan hanya endpoint yang Anda miliki atau berwenang untuk diuji. Sepakati jendela dan laju pengujian agar latihan tidak mengganggu layanan normal. Alat seperti iperf3 menyediakan arah, durasi dan aliran paralel yang dapat dikonfigurasi; dokumentasi resmi mendefinisikan kontrol tersebut. Catat versi, endpoint, konteks rute dan pengaturan beserta hasilnya agar operator lain dapat mereproduksinya.
Mulailah dengan satu aliran, lalu tambahkan konkurensi yang representatif. Jalankan kedua arah jika aplikasi bergantung pada keduanya. Matriks ilustratif ini memisahkan pertanyaan yang akan tercampur oleh satu hasil utama. Simpan hasil mentah secara privat ketika mengungkap alamat internal atau detail operasional, dan publikasikan hanya pengukuran yang diperlukan untuk keputusan.
| Pengujian | Apa yang diselidiki | Apa yang tidak dibuktikan |
|---|---|---|
| Satu aliran transport | Perilaku jalur aliran tunggal | Pengiriman aplikasi agregat |
| Beberapa aliran paralel | Konkurensi dan batas agregat | Laju transfer satu pelanggan |
| Transfer aplikasi | Penyimpanan, protokol dan perangkat lunak secara bersamaan | Kinerja untuk setiap kumpulan data |
| Pengulangan periode sibuk | Variasi di bawah aktivitas realistis | Jaminan throughput permanen |
Lihat endpoint selama pengujian
Catat penggunaan CPU, tekanan memori, aktivitas penyimpanan dan penghitung kesalahan di kedua ujung. Hasil transfer tanpa pengamatan endpoint dapat membuat kendala sebenarnya tidak terlihat. Periksa apakah satu proses atau CPU jenuh sementara yang lain menganggur. Hindari mengubah beberapa pengaturan sekaligus, karena itu menyulitkan identifikasi penyesuaian mana yang membantu.
Pisahkan pengujian berbasis memori dari pengujian yang membaca dan menulis data nyata. Yang pertama dapat membantu menyelidiki jalur transport; yang terakhir lebih mencerminkan pekerjaan aplikasi. Jika hasilnya sangat berbeda, periksa penyimpanan dan pemrosesan daripada menganggap angka berbasis memori sebagai janji pengiriman. Kedua pengukuran dapat berguna ketika cakupannya jelas.
Uji aplikasi dengan payload yang realistis
Ekspor HTTP, aliran replikasi terenkripsi dan sesi transfer file memiliki pola pemrosesan yang berbeda. Gunakan ukuran file, laju permintaan dan pengaturan enkripsi yang representatif. Sertakan waktu yang dihabiskan untuk menyiapkan data sebelum byte pertama dikirim ketika pengguna menunggu langkah tersebut. Bedakan latensi respons pertama dari waktu penyelesaian alih-alih melaporkan yang satu sebagai yang lain.
Ulangi pengujian pada interval yang cukup untuk melihat variasi, dan simpan baseline sebelum mengubah konfigurasi. Untuk ekspor 2 TB hipotetis, bandingkan waktu penyelesaian sebenarnya dengan jendela dua jam dan sisakan margin untuk gangguan. Pilih peningkatan berdasarkan kemacetan yang diamati daripada mengalikan kapasitas port tanpa alasan.
Gunakan hasilnya untuk memilih konfigurasi
Output yang berguna adalah kebutuhan sumber daya dengan bukti: laju payload terukur, waktu penyelesaian yang dapat diterima, konkurensi yang diharapkan dan tahap pembatas yang diketahui. Bandingkan varian jaringan SwissOctet terhadap kebutuhan itu, termasuk tunjangan lalu lintas serta spesifikasi CPU dan penyimpanan. Lokasi saja tidak menentukan rute atau latensi end-to-end ke setiap penerima.
Simpan prosedur pengujian setelah penerapan. Gunakan kembali saat kumpulan data bertambah, perangkat lunak berubah atau pengguna berpindah ke jaringan yang berbeda. Baseline yang dapat diulang memudahkan diagnosis insiden kinerja dan memberikan alasan yang lebih kuat untuk mengubah konfigurasi daripada uji kecepatan terisolasi atau maksimum yang diiklankan.
Daftar periksa praktis Anda.
- Hitung laju payload dari volume dan tenggat waktu.
- Modelkan transfer yang tumpang tindih dan arahnya.
- Sepakati endpoint pengujian yang berwenang dan batasnya.
- Bandingkan satu aliran, konkurensi dan pengujian aplikasi.
- Amati kedua endpoint selama pengujian.
- Pertahankan baseline yang dapat diulang dan margin yang berguna.
Detail yang penting.
Apakah jendela TCP yang lebih besar selalu memperbaiki transfer yang lambat?+
Tidak. Diagnosis jalur dan endpoint terlebih dahulu. Penyimpanan, CPU, kehilangan paket dan perilaku aplikasi dapat mendominasi, dan penyetelan transport harus sesuai dengan sistem yang sebenarnya.
Mengapa menguji satu aliran dan beberapa aliran?+
Keduanya menjawab pertanyaan yang berbeda. Kapasitas agregat dapat lebih tinggi daripada laju satu transfer; konkurensi aplikasi menentukan hasil mana yang penting.
Dapatkah saya menjalankan uji kapasitas terhadap server publik mana pun?+
Gunakan endpoint yang Anda kendalikan atau memiliki izin untuk diuji. Sepakati durasi, laju dan waktu agar pengukuran tidak mengganggu layanan yang tidak terkait.
Kunjungi sumbernya.
Referensi ini mendukung konsep teknis dalam panduan ini. Ikuti dokumentasi terkini sebelum mengubah sistem produksi.
- IETF RFC 6349: Kerangka kerja untuk pengujian throughput TCP datatracker.ietf.org
- ESnet: Memanggil iperf3 software.es.net
Panduan editorial oleh SwissOctet. Contoh bersifat ilustratif. Spesifikasi layanan, opsi yang tersedia, dan ketentuan kontraktual harus diverifikasi secara terpisah.