Saya memiliki server web dengan koneksi 100Mbit saat ini dan penyedia saya menawarkan peningkatan ke 1Gbit. Saya mengerti bahwa ini mengacu pada throughput tetapi semakin besar paket, semakin cepat mereka dapat ditransmisikan juga, jadi saya akan mengharapkan sedikit penurunan dalam waktu respon (misalnya ping). Apakah ada yang pernah membandingkan ini?
Contoh (server 100mbit ke 100mbit) dengan beban 30 byte:
> ping server -i0.05 -c200 -s30
[...]
200 packets transmitted, 200 received, 0% packet loss, time 9948ms
rtt min/avg/max/mdev = 0.093/0.164/0.960/0.093 ms
Contoh (server 100mbit ke 100mbit) dengan beban 300 byte (yang di bawah MTU):
> ping server -i0.05 -c200 -s300
[...]
200 packets transmitted, 200 received, 0% packet loss, time 10037ms
rtt min/avg/max/mdev = 0.235/0.395/0.841/0.078 ms
Jadi dari 30 hingga 300 rata-rata. latensi meningkat dari 0,164 ke 0,395 - Saya berharap ini akan menjadi peningkatan yang lebih lambat untuk koneksi 1gibt ke 1gbit. Saya bahkan berharap 100mbit ke 1gbit menjadi lebih cepat, jika koneksi melalui switch yang pertama menunggu hingga menerima seluruh paket.
Pembaruan: Harap baca komentar untuk jawaban dengan cermat! Koneksi tidak jenuh, dan saya tidak berpikir bahwa peningkatan kecepatan ini akan menjadi masalah bagi manusia untuk satu permintaan, tetapi ini tentang banyak permintaan yang bertambah (Redis, Database, dll.).
Mengenai jawaban dari @LatinSuD :
> ping server -i0.05 -c200 -s1400
200 packets transmitted, 200 received, 0% packet loss, time 9958ms
rtt min/avg/max/mdev = 0.662/0.866/1.557/0.110 ms
sumber
Jawaban:
Satu-satunya cara latensi akan menurun adalah jika tautan 100Mbit saat ini jenuh. Jika tidak jenuh, Anda mungkin tidak akan melihat adanya perubahan.
Selain itu, asumsi Anda bahwa tautan 1Gbit akan dapat mendukung paket yang lebih besar salah. Ukuran paket maks ditentukan oleh MTU dari berbagai perangkat di sepanjang jalur yang diambil paket - dimulai dengan NIC di server Anda, hingga MTU komputer pelanggan Anda. Dalam aplikasi LAN internal (ketika Anda memiliki kontrol atas semua perangkat di sepanjang jalan), kadang-kadang mungkin untuk meningkatkan MTU, tetapi dalam situasi ini, Anda cukup banyak terjebak dengan MTU default 1500. Jika Anda mengirim paket lebih besar dari bahwa, mereka pada akhirnya akan terfragmentasi, dengan demikian sebenarnya menurunkan kinerja.
sumber
YA gbit memiliki latensi lebih rendah, karena:
TETAPI peningkatan hanya dapat diterima jika paket memiliki ukuran tertentu:
Jadi jika Anda memiliki aplikasi yang sangat sensitif terhadap latensi (4ms vs 0.8ms, pulang pergi untuk 20kb) dan memerlukan paket yang lebih besar untuk ditransfer, daripada beralih dari 100mbit ke gbit dapat memberi Anda pengurangan latensi, meskipun Anda menggunakan jauh lebih sedikit daripada rata-rata 100mbit / s (= tautan tidak jenuh secara permanen).
Server (100mbit) -> Ganti (gbit) -> Server (100mbit):
Server (gbit) -> Ganti (gbit) -> Server (gbit):
= rata-rata pada beberapa server, pengurangan latensi 80% untuk ping 20kb
(Jika hanya salah satu tautannya adalah gbit, Anda masih akan memiliki pengurangan latensi 5% untuk ping 20kb.)
sumber
Saya pikir Anda memiliki kesalahpahaman mendasar tentang latensi bandwidth dan "kecepatan". Kecepatan adalah fungsi bandwidth dan latensi. Sebagai contoh, pertimbangkan pengiriman data pada DVD yang dikirim ke seluruh negeri membutuhkan waktu 3 hari untuk sampai. Bandingkan dengan mengirim data melalui internet. Internet memiliki koneksi latensi yang jauh lebih rendah, tetapi untuk mencocokkan "kecepatan" koneksi dengan kiriman Anda harus menerima pada 9,6MB per detik ( contoh referensi dari sumber ini ).
Dalam kasus Anda meningkatkan ke bandwidth yang lebih tinggi akan memungkinkan Anda untuk melayani lebih banyak pengguna secara bersamaan tetapi tidak meningkatkan latensi untuk setiap pengguna.
sumber
Anda melihat dunia melalui lubang jarum. Tes valid perbedaan latensi pada kecepatan yang berbeda akan antara dua NIC identik terhubung dengan kabel cross-connect. Atur kecepatan NIC untuk matematika 10mb, 100mb, dan 1000mb. Ini akan menunjukkan bahwa hampir tidak ada perbedaan dalam latensi pada kecepatan yang berbeda. Semua paket berjalan dengan kecepatan kabel yang sama terlepas dari bandwidth maksimum yang digunakan. Setelah Anda menambahkan sakelar dengan simpan dan teruskan tembolok semua perubahan. Pengujian latensi melalui sakelar harus dilakukan hanya dengan dua koneksi sakelar. Lalu lintas lain apa pun dapat memengaruhi latensi pengujian Anda. Bahkan kemudian saklar dapat roll-over log, menyesuaikan penghitung tipe paket, memperbarui jam internal, dll. Semuanya dapat mempengaruhi latensi.
Ya, beralih dari 100mb ke 1gb mungkin lebih cepat (latensi lebih rendah) karena perubahan perangkat keras, NIC berbeda, saklar berbeda, driver berbeda. Saya telah melihat perubahan yang lebih besar dalam latensi ping dari perbedaan driver daripada perubahan lainnya; bandwidth, switch, offloading NIC, dll.
Switch akan menjadi perubahan terbesar berikutnya dengan cut-through yang secara signifikan lebih cepat daripada store and forward untuk tes transmisi tunggal. Namun, toko yang dirancang dengan baik dan sakelar maju dapat melampaui sakelar cut-through dalam kinerja keseluruhan di bawah beban tinggi. Pada hari-hari awal gigabit saya telah melihat 10MB switch backplane kinerja tinggi dengan latensi lebih rendah daripada switch gigabit murah.
Tes Ping praktis tidak relevan untuk analisis kinerja saat menggunakan Internet. Mereka adalah tes cepat untuk mendapatkan gambaran kasar tentang apa yang terjadi pada transportasi pada saat tes. Pengujian kinerja produksi jauh lebih rumit dari sekadar ping. Switch berperforma tinggi adalah komputer dan di bawah beban tinggi berperilaku berbeda - perubahan latensi.
Memiliki NIC yang lebih lambat, atau NIC yang diatur ke kecepatan yang lebih lambat, sebenarnya dapat membantu server dengan semburan bersamaan dengan membatasi input ke server menggunakan cache switch. Pengiriman ulang tunggal dapat meniadakan penurunan latensi. Biasanya tingkat lalu lintas sedang hingga tinggi penting, bukan tes ping tunggal. mis. Sun Ultrasparc lama yang lambat (latensi lebih tinggi untuk satu ping) mengungguli desktop gigabit murah baru yang digunakan sebagai server dev ketika beban bandwidth di bawah 70% 100mb. Desktop memiliki gb NIC yang lebih cepat, koneksi gb-gb yang lebih cepat, memori yang lebih cepat, memori yang lebih banyak, disk yang lebih cepat, dan prosesor yang lebih cepat tetapi tidak berfungsi sebaik perangkat keras / lunak kelas server yang disetel. Ini bukan untuk mengatakan bahwa server yang disetel saat ini yang menjalankan gb-gb tidak lebih cepat dari perangkat keras lama, bahkan dapat menangani beban throughput yang lebih besar. Ada lebih banyak kompleksitas pada pertanyaan "
Cari tahu apakah penyedia Anda menggunakan sakelar yang berbeda untuk koneksi 100mb vs. 1gb. Jika mereka menggunakan saklar backplane yang sama dari saya hanya akan membayar kenaikan jika tingkat lalu lintas melebihi bandwidth yang lebih rendah. Kalau tidak, Anda mungkin menemukan bahwa dalam waktu singkat banyak pengguna lain akan beralih ke gigabit dan beberapa pengguna yang tersisa di sakelar lama sekarang memiliki kinerja lebih tinggi - latensi lebih rendah, selama beban tinggi pada sakelar (beban sakelar keseluruhan, tidak hanya ke server Anda ).
Contoh apel dan jeruk: ISP lokal menyediakan switch baru untuk layanan paket, DSL, dan telepon. Awalnya pengguna melihat peningkatan kinerja. Sistem sudah oversold. Sekarang pengguna yang tetap menggunakan sakelar lama memiliki kinerja konsisten yang lebih tinggi. Pada larut malam, pengguna pada sistem baru lebih cepat. Di malam hari di bawah beban tinggi, klien switch lama jelas mengungguli sistem kelebihan beban baru.
Latensi yang lebih rendah tidak selalu berkorelasi dengan pengiriman yang lebih cepat. Anda menyebutkan MySQl dalam 20 permintaan untuk melayani satu halaman. Lalu lintas itu seharusnya tidak berada di NIC yang sama dengan permintaan halaman. Memindahkan semua lalu lintas internal ke jaringan internal akan mengurangi tabrakan dan jumlah paket total pada NIC keluar dan memberikan keuntungan yang lebih besar daripada kenaikan latensi 0,04 ms dari satu paket. Kurangi jumlah permintaan per halaman untuk mengurangi latensi pemuatan halaman. Kompres halaman, html, css, javascript, gambar untuk mengurangi waktu pemuatan halaman. Ketiga perubahan ini akan memberikan keuntungan keseluruhan yang lebih besar daripada membayar bandwidth yang tidak digunakan untuk mendapatkan pengurangan latensi 0,04 ms. Ping perlu menjalankan 24 jam dan dirata-rata untuk melihat perubahan latensi nyata. Smart switch sekarang melakukan throttling tipe RTSP adaptif dengan peningkatan bandwidth awal kecil dan transfer besar dibatasi. Bergantung pada ukuran halaman Anda (grafik, html / css / javascript besar), Anda mungkin melihat latensi / bandwidth koneksi awal jauh lebih rendah / lebih tinggi daripada halaman besar atau transfer halaman penuh. Jika bagian dari halaman Anda mengalir, Anda mungkin melihat kinerja yang sangat berbeda antara halaman dan aliran.
sumber
Mari kita asumsikan paket 300 byte (jika Anda menggunakannya
-s 300akan lebih besar karena header).0,024ms kira-kira waktu aktual yang diperlukan untuk mengirim bingkai (tidak termasuk waktu akses menengah atau tajuk).
Dalam urutan ping-pong itu akan memakan waktu dua kali lipat (0,048 ms), ditambah waktu bagi OS untuk memproses kueri.
Itu berarti bagi saya bahwa latensi Anda disebabkan oleh 90% dari beberapa faktor overhead. Saya tidak yakin apakah Anda akan melihat banyak perbedaan dengan Gb. Perbedaan yang mungkin kurang dari 1 ms tidak akan terlihat sebagai server web.
Lagi pula bisakah Anda mencoba dengan paket yang sangat besar seperti 1400 byte?
sumber
Ini tergantung pada jenis sakelar yang Anda hubungkan. Pada beberapa vendor (seperti Crisco ... maksud saya Cisco), paket ICMP akan mengalir kembali ke CPU ( muntah ).
Anda mungkin menemukan tes yang lebih baik adalah melakukan tes host-ke-host menggunakan tautan 100Mbps dan 1Gbps (yaitu bukan tes host-to-switch atau host-to-router).
Pada akhir hari, latensi akan turun ke tingkat penerusan switch dan rincian arsitektur switch (di mana ASIC ditempatkan di papan, bagaimana penguncian ditangani antara kartu garis, dll). Semoga berhasil dengan pengujian Anda.
sumber