हमें दुनिया भर के कुछ प्रमुख स्थानों - सिंगापुर, लंदन और लॉस एंजिल्स में बुनियादी ढांचे का वितरण किया गया है। किसी भी दो स्थानों के बीच RTT> 150ms से अधिक है।
हमने हाल ही में 1Gbps लिंक (100Mbps से) का उपयोग करने के लिए सभी सर्वरों को अपग्रेड किया है। हम विभिन्न स्थानों पर सर्वर के बीच कुछ टीसीपी-आधारित परीक्षण चला रहे हैं और कुछ आश्चर्यजनक परिणाम देखे हैं। ये परिणाम पूरी तरह से दोहराए जाने योग्य हैं।
- लॉस एंजिल्स (100Mbps) से लंदन (100Mbps): ~ 96Mbps थ्रूपुट
- लॉस एंजिल्स (100Mbps) से लंदन (1Gbps): ~ 96Mbps थ्रूपुट
- लॉस एंजिल्स (1Gbps) से लंदन (100Mbps): 10-40Mbps थ्रूपुट (अस्थिर)
- लॉस एंजिल्स (1Gbps) से लंदन (1Gbps): 10-40Mbps थ्रूपुट (अस्थिर)
- लॉस एंजिल्स (1Gbps) से लॉस एंजिल्स (1Gbps):> 900Mbps थ्रूपुट
ऐसा प्रतीत होता है कि जब भी प्रेषक 1Gbps पर चल रहा होता है, तो हमारा थ्रूपुट लंबे लिंक पर बहुत अधिक प्रभाव डालता है।
पहले का परीक्षण दृष्टिकोण बेहद सरल है - मैं सिर्फ लक्ष्य सर्वर से 1GB बाइनरी डाउनलोड करने के लिए cURL का उपयोग कर रहा हूं (इसलिए उपरोक्त मामले में, CURL क्लाइंट लंदन सर्वर पर चलता है और LA से डाउनलोड करता है, ताकि LA प्रेषक हो) । यह एकल टीसीपी कनेक्शन का उपयोग कर रहा है।
UDP पर iperf का उपयोग करके समान परीक्षणों को दोहराने से समस्या गायब हो जाती है!
- लॉस एंजिल्स (100Mbps) से लंदन (100Mbps): ~ 96Mbps थ्रूपुट
- लॉस एंजिल्स (100Mbps) से लंदन (1Gbps): ~ 96Mbps थ्रूपुट
- लॉस एंजिल्स (1Gbps) से लंदन (100Mbps): ~ 96Mbps थ्रूपुट
- लॉस एंजिल्स (1Gbps) से लंदन (1Gbps):> 250Mbps थ्रूपुट
यह मेरी आंखों में कुछ टीसीपी या एनआईसी / पोर्ट कॉन्फ़िगरेशन इश्यू पर स्क्वायर पॉइंट करता है।
दोनों सर्वर टीसीपी क्यूबिक के साथ CentOS 6.x चला रहे हैं। दोनों में 8MB अधिकतम टीसीपी विंडोज़ भेजने और प्राप्त करने की है, और टीसीपी टाइमस्टैम्प और चयनात्मक स्वीकृति सक्षम है। सभी परीक्षण मामलों में एक ही टीसीपी कॉन्फ़िगरेशन का उपयोग किया जाता है। पूर्ण टीसीपी विन्यास नीचे है:
net.core.somaxconn = 128
net.core.xfrm_aevent_etime = 10
net.core.xfrm_aevent_rseqth = 2
net.core.xfrm_larval_drop = 1
net.core.xfrm_acq_expires = 30
net.core.wmem_max = 8388608
net.core.rmem_max = 8388608
net.core.wmem_default = 131072
net.core.rmem_default = 131072
net.core.dev_weight = 64
net.core.netdev_max_backlog = 1000
net.core.message_cost = 5
net.core.message_burst = 10
net.core.optmem_max = 20480
net.core.rps_sock_flow_entries = 0
net.core.netdev_budget = 300
net.core.warnings = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_retrans_collapse = 1
net.ipv4.tcp_syn_retries = 5
net.ipv4.tcp_synack_retries = 5
net.ipv4.tcp_max_orphans = 262144
net.ipv4.tcp_max_tw_buckets = 262144
net.ipv4.tcp_keepalive_time = 7200
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_intvl = 75
net.ipv4.tcp_retries1 = 3
net.ipv4.tcp_retries2 = 15
net.ipv4.tcp_fin_timeout = 60
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_abort_on_overflow = 0
net.ipv4.tcp_stdurg = 0
net.ipv4.tcp_rfc1337 = 0
net.ipv4.tcp_max_syn_backlog = 2048
net.ipv4.tcp_orphan_retries = 0
net.ipv4.tcp_fack = 1
net.ipv4.tcp_reordering = 3
net.ipv4.tcp_ecn = 2
net.ipv4.tcp_dsack = 1
net.ipv4.tcp_mem = 1528512 2038016 3057024
net.ipv4.tcp_wmem = 4096 131072 8388608
net.ipv4.tcp_rmem = 4096 131072 8388608
net.ipv4.tcp_app_win = 31
net.ipv4.tcp_adv_win_scale = 2
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_frto = 2
net.ipv4.tcp_frto_response = 0
net.ipv4.tcp_low_latency = 0
net.ipv4.tcp_no_metrics_save = 0
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_tso_win_divisor = 3
net.ipv4.tcp_congestion_control = cubic
net.ipv4.tcp_abc = 0
net.ipv4.tcp_mtu_probing = 0
net.ipv4.tcp_base_mss = 512
net.ipv4.tcp_workaround_signed_windows = 0
net.ipv4.tcp_dma_copybreak = 4096
net.ipv4.tcp_slow_start_after_idle = 1
net.ipv4.tcp_available_congestion_control = cubic reno
net.ipv4.tcp_allowed_congestion_control = cubic reno
net.ipv4.tcp_max_ssthresh = 0
net.ipv4.tcp_thin_linear_timeouts = 0
net.ipv4.tcp_thin_dupack = 0
संलग्न कुछ परीक्षण मामलों के तारचोर IO ग्राफ की छवियों के एक जोड़े हैं (क्षमा करें, मैं अभी तक सीधे चित्र पोस्ट नहीं कर सकता):
टेस्ट केस 1 (100Mbps -> 100Mbps) - अच्छा स्मूद ट्रांसफर। कैद में कोई नुकसान नहीं। - http ://103.imagebam.com/download/dyNftIGh-1iCFbjfMFvBQw/25498/254976014/100m.png
टेस्ट केस 3 (1Gbps -> 100Mbps) - वोटेल ट्रांसफर, किसी भी गति को प्राप्त करने में लंबा समय लेता है - कभी भी 100Mbps तक नहीं पहुंचता है। अभी तक कोई नुकसान / कब्जा में retransmits! - http://101.imagebam.com/download/KMYXHrLmN6l0Z4KbUYEZnA/25498/254976007/1g.png
इसलिए सारांश में, जब 1Gbps कनेक्शन के साथ एक लंबी लिंक का उपयोग किया जाता है, तो जब हम 100Mbps कनेक्शन का उपयोग करते हैं, तो हमें टीसीपी थ्रूपुट बहुत कम मिलता है।
मैं किसी भी टीसीपी विशेषज्ञों के कुछ संकेत की बहुत सराहना करता हूँ!
धन्यवाद!
अद्यतन (2013-05-29):
हमने परीक्षण मामले को # 4 ऊपर (1 जीबीपीएस प्रेषक, 1 जीबीपीएस रिसीवर, एक बड़े आरटीटी से अधिक) के साथ हल किया है। अब हम स्थानांतरण शुरू होने के कुछ सेकंड के भीतर ~ 970Mbps हिट कर सकते हैं। ऐसा प्रतीत होता है कि होस्टिंग प्रदाता के साथ एक स्विच का उपयोग किया गया है। एक अलग करने के लिए चल रहा है कि हल।
हालाँकि, टेस्ट केस # 3 ज्यादातर समस्याग्रस्त रहता है। यदि हमारे पास 100Mbps पर चलने वाला एक रिसीवर और 1Gbps पर भेजने वाला है, तो हमें रिसीवर को 100Mbps तक पहुंचने के लिए लगभग 2-3 मिनट का इंतजार है (लेकिन यह अब पहले की तुलना में पूर्ण दर पर पहुंचता है)। जैसे ही हम प्रेषक को 100Mbps से कम करते हैं या रिसीवर को 1Gbps तक बढ़ाते हैं, तब समस्या गायब हो जाती है और हम एक या दो मिनट में पूरी गति तक रैंप पर आ सकते हैं।
अंतर्निहित कारण यह है कि हम नुकसान देख रहे हैं, निश्चित रूप से, स्थानांतरण शुरू होने के तुरंत बाद। हालांकि, यह मेरी समझ से मेल नहीं खाता है कि धीमी गति से काम कैसे शुरू होता है; इंटरफ़ेस की गति का इस पर कोई असर नहीं होना चाहिए, क्योंकि इसे रिसीवर से ACKs द्वारा नियंत्रित किया जाना चाहिए।
कृपया कृतज्ञतापूर्वक सुझाव प्राप्त करें! अगर मैं यहाँ एक इनाम की पेशकश कर सकता, मैं करूँगा!
tcp_*mem = 4096 1048576 33554432आपने 1Gbps लिंक पर जंबो फ्रेम्स को सक्षम नहीं किया है? यह कहीं न कहीं विखंडन का कारण बन सकता है।