Debugging kecepatan transfer lambat dari server


9

Saya mencoba menjelaskan ini sesederhana mungkin tetapi didokumentasikan. Ini tidak eksklusif untuk server ini atau ISP saya saat ini . Saya telah melihat masalah yang persis sama selama bertahun-tahun ketika berada dengan ISP yang berbeda dan memiliki server saya dengan penyedia yang berbeda (GoDaddy di AS, iWeb dan GloboTech di Kanada). Satu-satunya hal yang sudah umum adalah OS Windows Server (2003 dan 2008 r2). Tapi mari kita lihat sekarang di server saya saat ini dan ISP saya saat ini saja.

Masalahnya :

Saya mendapatkan kecepatan transfer yang sangat lambat antara workstation lokal saya dan server khusus jarak jauh saya. Server saya pada port 100 Mbps dan workstation lokal saya pada koneksi simetrik 50 Mbps di atas serat optik.

Gejala :

Baik server dan workstation mendapatkan hasil yang sangat baik (sangat dekat dengan kecepatan koneksi mereka) ketika melakukan tes pada speedtest.net terhadap berbagai server dan lokasi di AS dan Meksiko. Jika saya mengunduh file besar dari, katakanlah, Dropbox, ke server saya atau workstation saya, saya mendapatkan kecepatan transfer masing-masing 10 MBps dan 5 MBps pada satu koneksi, yang benar sesuai dengan setiap kecepatan koneksi 100 Mbps dan 50 Mbps secara repektif

Namun, jika saya mentransfer file dari server saya (melalui HTTP atau FTP) ke workstation saya, saya bahkan tidak mendekati kecepatan 50 Mbps yang seharusnya saya dapatkan (transfer rate 5 MBps) tetapi saya mendapatkan sesuatu yang setara dengan 3 Mbps (300 KBps transfer rate).

Saya mencoba memahami mengapa saya mendapatkan kecepatan transfer yang lambat. Saya tidak yakin tentang cara men-debug itu. Setiap kali saya menaikkan tiket pada masalah dengan penyedia hosting, mereka meminta saya untuk tracert output dan akhirnya hanya menyalahkan pada beberapa server di tengah. Tapi itu tampaknya tidak benar, jika kita mempertimbangkan apa yang saya katakan pada awalnya: Saya telah melihat kecepatan / masalah yang tepat ini ketika memiliki server saya dengan GoDaddy, iWeb dan GloboTech, dan sementara saya sendiri dengan berbagai ISP pada berbagai jenis layanan Internet . Ini benar-benar terlihat seperti pengaturan tetap di suatu tempat di area server.

Tes yang telah saya lakukan :

TES KECEPATAN

Ini adalah tes kecepatan dari speedtest.net yang dijalankan di server khusus saya terhadap server jarak jauh yang berbeda termasuk server di pusat data ISP saya di Mexico City:

Kanada : 94,64 Mbps untuk diunduh dan 94,87 untuk diunggah http://www.speedtest.net/my-result/3470801975

San Jose, CA : 93,58 Mbps untuk diunduh dan 95,48 Mbps untuk diunggah http://www.speedtest.net/my-result/3470805341

Mexico City (server di datacanter ISP saya sendiri) : 92,99 Mbps untuk diunduh dan 95,39 Mbps untuk diunggah http://www.speedtest.net/my-result/3470810269

Jika saya menjalankan tes-tes itu terhadap server yang sama dari workstation lokal saya, saya mendapatkan kecepatan mendekati koneksi 50 Mbps saya juga.

TRACERT

Ini adalah keluaran tracert terbaru yang dijalankan dari workstation saya ke server khusus saya:

 1    <1 ms    <1 ms    <1 ms  192.168.7.254
 2     2 ms     1 ms     1 ms  10.69.32.1
 3     *        3 ms     2 ms  10.5.50.174
 4     3 ms     2 ms     2 ms  10.5.50.173
 5     *        5 ms     3 ms  fixed-203-69-2.iusacell.net [189.203.69.2]
 6    32 ms    32 ms    32 ms  8-1-33.ear1.Dallas1.Level3.net [4.71.220.89]
 7    33 ms    33 ms    33 ms  ae-3-80.edge5.Dallas3.Level3.net [4.69.145.145]
 8    33 ms    33 ms    33 ms  ae13.dal33.ip4.tinet.net [77.67.71.221]
 9    76 ms    76 ms   157 ms  xe-1-0-0.mtl10.ip4.tinet.net [89.149.185.41]
10    72 ms    72 ms    72 ms  te2-2.cr2.mtl3.gtcomm.net [67.215.0.160]
11    72 ms    72 ms    72 ms  ae2.csr2.mtl3.gtcomm.net [67.215.0.134]
12    72 ms    72 ms    73 ms  te3-4.dist1.mtl8.gtcomm.net [67.215.0.83]
13    72 ms    72 ms    72 ms  ns1.marveldns.com [173.209.57.82]

IPERF

Ini adalah tes iperf yang dieksekusi menggunakan server khusus saya sebagai server dan workstation saya sebagai klien:

------------------------------------------------------------
Client connecting to ns1.marveldns.com, TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.7.2 port 60339 connected with 173.209.57.82 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.3 sec  5.62 MBytes  4.59 Mbits/sec

PERJALANAN

Ini adalah output dari pathping commend yang dieksekusi dari workstation saya ke server khusus saya:

Tracing route to ns1.marveldns.com [173.209.57.82]
over a maximum of 30 hops:
  0  ws1 [192.168.7.2]
  1  192.168.7.254
  2  10.69.32.1
  3     *     10.5.50.174
  4  10.5.50.173
  5  fixed-203-69-2.iusacell.net [189.203.69.2]
  6  8-1-33.ear1.Dallas1.Level3.net [4.71.220.89]
  7  ae-3-80.edge5.Dallas3.Level3.net [4.69.145.145]
  8  ae13.dal33.ip4.tinet.net [77.67.71.221]
  9  xe-1-0-0.mtl10.ip4.tinet.net [89.149.185.41]
 10  te2-2.cr2.mtl3.gtcomm.net [67.215.0.160]
 11  ae2.csr2.mtl3.gtcomm.net [67.215.0.134]
 12  te3-4.dist1.mtl8.gtcomm.net [67.215.0.83]
 13  ns1.marveldns.com [173.209.57.82]

Computing statistics for 325 seconds...
            Source to Here   This Node/Link
Hop    RTT  Lost/Sent = Pct  Lost/Sent = Pct  Address
  0                                           ws1 [192.168.7.2]
                                0/ 100 =  0%   |
  1    0ms     0/ 100 =  0%     0/ 100 =  0%  192.168.7.254
                                0/ 100 =  0%   |
  2    1ms     0/ 100 =  0%     0/ 100 =  0%  10.69.32.1
                                0/ 100 =  0%   |
  3    3ms     0/ 100 =  0%     0/ 100 =  0%  10.5.50.174
                                0/ 100 =  0%   |
  4    2ms     0/ 100 =  0%     0/ 100 =  0%  10.5.50.173
                                0/ 100 =  0%   |
  5    4ms    20/ 100 = 20%    20/ 100 = 20%  fixed-203-69-2.iusacell.net [189.203.69.2]
                                0/ 100 =  0%   |
  6   34ms     0/ 100 =  0%     0/ 100 =  0%  8-1-33.ear1.Dallas1.Level3.net [4.71.220.89]
                                0/ 100 =  0%   |
  7   34ms     0/ 100 =  0%     0/ 100 =  0%  ae-3-80.edge5.Dallas3.Level3.net [4.69.145.145]
                                0/ 100 =  0%   |
  8   33ms     0/ 100 =  0%     0/ 100 =  0%  ae13.dal33.ip4.tinet.net [77.67.71.221]
                                0/ 100 =  0%   |
  9   79ms     0/ 100 =  0%     0/ 100 =  0%  xe-1-0-0.mtl10.ip4.tinet.net [89.149.185.41]
                                2/ 100 =  2%   |
 10   73ms    14/ 100 = 14%    12/ 100 = 12%  te2-2.cr2.mtl3.gtcomm.net [67.215.0.160]
                                0/ 100 =  0%   |
 11   72ms     2/ 100 =  2%     0/ 100 =  0%  ae2.csr2.mtl3.gtcomm.net [67.215.0.134]
                                2/ 100 =  2%   |
 12   72ms    18/ 100 = 18%    14/ 100 = 14%  te3-4.dist1.mtl8.gtcomm.net [67.215.0.83]
                                0/ 100 =  0%   |
 13   72ms     4/ 100 =  4%     0/ 100 =  0%  ns1.marveldns.com [173.209.57.82]

Trace complete.

Hal yang bisa Anda coba sendiri

Jika Anda ingin mencobanya, ini adalah beberapa hal yang saya siapkan di server untuk tujuan pengujian:

File besar di server HTTP

Saya telah menempatkan file 5 GB di server saya yang dapat diunduh melalui HTTP. Anda dapat menemukannya di sini: http://www.marveldns.com/transfer_test/

Aplikasi MINI Speedtest

Saya telah menyiapkan tes "speedtest mini" di server saya. Anda dapat mengunjunginya dan melihat kecepatan yang dikatakannya untuk mengunduh dan mengunggah di server saya dan diri Anda sendiri. Anda dapat menemukannya di sini: http://www.marveldns.com/speedtest/

Akhirnya :

Seperti yang saya katakan sebelumnya, saya berusaha mendapatkan bantuan untuk memahami semuanya. Saya bukan ahli TCP / IP atau jaringan ujung atas. Jujur saya bahkan tidak jelas bagaimana menggunakan hasil tracert, iperf atau pingpath untuk dapat menyelesaikan masalah, tetapi saya memasukkannya karena saya selalu memintanya ketika saya berbicara tentang masalah ini.

Jika pertanyaan saya kekurangan sesuatu untuk menjadi lebih baik, tolong jangan hanya downvote dan biarkan saya tahu apa yang salah dengan itu atau apa lagi yang bisa saya tambahkan untuk mendapatkan bantuan. Terima kasih.


hanya karena saya ingin tahu, berapa kecepatan yang Anda miliki ketika Anda meletakkan file di localhost di server khusus Anda?
Brice

Hai Brice. Saya mendapatkan sesuatu sekitar 50 MB / s (byte, bukan bit), yang kecepatannya hampir sama dengan yang saya dapatkan jika saya menyalin file secara manual ke folder yang sama di disk yang sama langsung di Windows Explorer (jadi dibatasi oleh kecepatan disk saat membaca dari dan menulis sendiri).
Francisco Zarabozo

1
Menurut tracert, workstation Anda berada di jaringan yang agak besar. Sudahkah Anda mencoba bertanya kepada administrator jaringan lokal apakah ada semacam Qo yang akan memperlambat koneksi?

Jika Anda memulai lebih dari satu transfer secara bersamaan, apakah kecepatan gabungannya mencapai mendekati 50Mbit / s yang diharapkan? yaitu. Apakah lambat, atau lambat per koneksi?
Berikan

@Grant: Dengan beberapa koneksi, iklannya mencapai 50 Mbps. Batas terjadi per koneksi.
Francisco Zarabozo

Jawaban:


9

Kemacetan yang saya lihat ketika mengakses URL itu jelas karena ukuran jendela.

Ketika saya mencoba mengunduh dari server Anda, saya mendapatkan 555KB / s. Saya memiliki waktu pulang pergi 108ms. Melakukan perhitungan matematika saya mendapatkan ukuran jendela berikut: 555KB / s * 108ms = 59.94KB.

Selama saya melakukannya dari host di pusat data, saya mendapatkan throughput dan bolak-balik yang sangat konsisten. Selain itu, jika saya memulai dua unduhan secara paralel masing-masing mendapatkan 555KB / s. Itulah gejala yang akan Anda lihat ketika bottleneck adalah ukuran jendela.

Tanpa penskalaan jendela, jendela tidak boleh lebih besar dari 64KB. Tapi saya melihat skala jendela dinegosiasikan, jadi throughput yang lebih tinggi harus dimungkinkan. Ini meninggalkan dua hipotesis untuk menyelidiki:

  • Ada sesuatu yang membingungkan pilihan penskalaan jendela di jalur dari klien ke server membuat server berpikir bahwa jendela ditingkatkan oleh faktor 1.
  • Server dapat dikonfigurasikan untuk tidak pernah menggunakan lebih dari 60KB jendela kirim pada setiap koneksi.

Yang pertama mudah diverifikasi jika Anda dapat melakukan penangkapan paket di server. Lihat saja opsi penskalaan pada paket SYN yang masuk untuk mengetahui apakah faktor penskalaan yang lebih tinggi dari yang diterima oleh server. Saya dapat merekomendasikan menggunakan Wireshark untuk menganalisis lalu lintas.

Memverifikasi hipotesis kedua membutuhkan pengetahuan tentang sistem operasi yang Anda gunakan. Anda kebetulan telah memilih sistem operasi, yang tidak saya ketahui, sehingga saya tidak dapat membantu. Jadi saya hanya bisa membantu dengan keahlian dalam jaringan.


Saya tidak 100% yakin, tetapi bukankah ukuran jendela dipengaruhi oleh soket yang mengirim dan menerima ukuran buffer (opsi soket SO_RVSBUF dan SO_SNDBUF)? Saya telah melihat insiden serupa di mana buffer terlalu kecil (mis. 1KB), dan throughput sangat terbatas dibandingkan dengan 4KB atau 8KB).
Cameron Kerr

@CameronKerr Komentar Anda mendorong saya untuk melihat lagi komunikasi. Kali ini saya menguji dari laptop saya (yang ada di WiFi dan mendapat throughput yang lebih rendah). Apa yang saya amati adalah saya mendapatkan 138KB / s dengan perjalanan pulang pergi 105 ms. Itu berarti ukuran jendela efektif 14,5KB. Jendela terima yang diiklankan oleh laptop saya tumbuh menjadi 679 << 7 (sekitar 85KB) sebelum throughput stabil. Itu harus mengesampingkan kemungkinan bahwa faktor penskalaan hanya memusatkan perhatian dalam perjalanan dan harus mengesampingkan kemungkinan bahwa throughput dibatasi oleh menerima buffer pada akhirnya.
kasperd

Artikel yang relevan untuk Windows Server 2008 r2 dapat ditemukan di sini: andydavies.me/blog/2011/11/21/…
Francisco Zarabozo
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.