Ferrari और Tractor Trailer

SMB दुनिया में काम करते हुए, यह वास्तव में काफी दुर्लभ है कि हमें latency के बारे में बात करने की जरूरत पड़े। SMB दुनिया लगभग सार्वभौमिक रूप से system throughput पर केंद्रित है और आम तौर पर latency को एक जरूरत के रूप में नहीं जानती। लेकिन ऐसे समय होते हैं जब latency महत्वपूर्ण हो जाती है और जब ऐसा होता है तो यह महत्वपूर्ण है कि हम throughput और latency की परस्परक्रिया को समझें और यह कि "speed" हमारे लिए क्या अर्थ रखती है। एक बार जब हम enterprise space में जाने लगते हैं, तो latency को अधिक बार एक चिंता के रूप में देखा जाएगा, लेकिन वहाँ भी throughput लगभग हमेशा सर्वोपरि रहती है, इस हद तक कि speed की अवधारणाएँ लगभग सार्वभौमिक रूप से throughput के इर्द-गिर्द घूमती हैं और latency की अवधारणाओं को अक्सर नजरअंदाज या भुला दिया जाता है।

किसी system में latency की भूमिका को समझना जटिल हो सकता है, भले ही latency स्वयं को समझना अपेक्षाकृत सरल हो।

Latency और throughput के बीच एक महान comparison जो मुझे उपयोग करना पसंद है वह है Ferrari और tractor trailer का विचार। Ferraris पारंपरिक अर्थ में "fast" हैं, उनके पास उच्च "miles per hour" है। कोई कह सकता है कि वे speed के लिए डिज़ाइन किए गए हैं। लेकिन क्या वे हैं?

हम आम तौर पर tractor trailers को धीमा मानते हैं। वे बड़े और भारी जानवर हैं जिनकी top end speed कम होती है। लेकिन वे एक साथ बहुत सारा सामान ढोते हैं।

Computer terms में हम सामान्यतः speed को hauling capacity की तरह सोचते हैं — हम "items" per second के terms में सोचते हैं। Ferrari के terms में दो सौ miles per hour जाना बढ़िया है, लेकिन यह एक बार में शायद एक box ही ले जा सकती है। एक tractor trailer केवल एक सौ miles per hour ही जा सकती है लेकिन एक बार में एक हजार boxes के करीब ले जा सकती है। जब हम computer पर throughput या speed के बारे में बात करते हैं तो यह अधिक वह है जो हम सोचते हैं। Network terms में हम gigabytes per second के बारे में सोचते हैं और एक individual packet की speed की शायद ही कभी परवाह करते हैं क्योंकि एक single packet शायद ही कभी महत्वपूर्ण होता है। Computational terms में हम floating point operations per second जैसी अवधारणाओं के बारे में सोचते हैं, एक समान अवधारणा। वास्तव में कोई भी परवाह नहीं करता कि एक single FLOP (floating point operation) में कितना समय लगता है, केवल इसकी परवाह करते हैं कि हम एक या दस seconds में कितने complete कर सकते हैं।

तो एक Ferrari को देखते हुए हम कह सकते हैं कि इसकी useful speed दो सौ box-miles per hour है। यानी operations के हर घंटे के लिए, एक Ferrari एक box को दो सौ miles तक ले जा सकती है। एक tractor trailer की useful speed एक लाख box-miles per hour है। Packages को इधर-उधर ले जाने के terms में, tractor trailer का throughput Ferrari से आसानी से पाँच सौ गुना "faster" है।

तो जिस तरह हम सामान्यतः computers और networks के बारे में सोचते हैं उसके terms में एक tractor trailer "fast" होगी और एक Ferrari "slow" होगी।

लेकिन latency पर भी विचार करना होगा। यह मानते हुए कि हमारा payload छोटा है, मान लीजिए एक letter या एक small box, एक Ferrari उस एक box को एक हजार miles में केवल पाँच घंटों में ले जा सकती है! एक tractor trailer को यही यात्रा करने में दस घंटे लगेंगे (लेकिन एक साथ बहुत सारे letters पहुँचा सकती है।) यदि हमें किसी message या small parcel को किसी स्थान से दूसरे स्थान पर बहुत जल्दी पहुँचाना है तो Ferrari बेहतर विकल्प है क्योंकि delivery शुरू करने के समय से लेकर पहला package delivered होने तक tractor trailer की तुलना में इसकी आधी latency (delay) है।

जैसा कि आप कल्पना कर सकते हैं, अधिकांश मामलों में tractor trailers बहुत अधिक व्यावहारिक हैं क्योंकि उनकी delivery speed बहुत अधिक है। और, यह मामला होने के कारण, हम वास्तव में highways पर बड़े trucks को हर समय देखते हैं और Ferraris की occurrence rate बहुत कम है — भले ही प्रत्येक की खरीद लागत लगभग समान हो (बहुत मोटे तौर पर।) लेकिन special cases में, Ferrari अधिक समझ में आती है। बस बहुत कम।

यह एक general case अवधारणा है और कई applications पर apply हो सकती है। यह caching systems, memory, CPU, networking, operating system kernels और schedulers, cars और अधिक पर apply होती है। Latency और throughput आम तौर पर inversely related होते हैं — हम throughput प्राप्त करने के लिए latency छोड़ते हैं। अधिकांश operations के लिए यह सबसे अच्छा समझ में आता है। लेकिन कभी-कभी latency के लिए tune करना अधिक समझदारी होती है।

Storage वास्तव में computing में एक odd duck है जहाँ storage performance पर लगभग सभी focus IOPS के आसपास है, जो latency के लिए लगभग एक proxy measurement है, बजाय throughput के जिसे "data transferred per second" में मापा जाता है। शायद ही कभी हम इस दूसरे number की परवाह करते हैं क्योंकि यह लगभग कभी भी storage bottlenecks का source नहीं है। लेकिन यह exception है, नियम नहीं।

Computing दुनिया में latency और throughput के कुछ आश्चर्यजनक interactions हो सकते हैं। जब हम networks के बारे में बात करते हैं, उदाहरण के लिए, हम आम तौर पर केवल throughput (Gb/s) मापते हैं लेकिन latency (आम तौर पर milliseconds में मापी गई) की बहुत कम परवाह करते हैं। आम तौर पर यह इसलिए है क्योंकि लगभग सभी networking systems में समान latency numbers होते हैं और अधिकांश applications latency delays से बहुत कम concerned होते हैं। यह केवल दुर्लभ applications जैसे International links या satellite पर VoIP हैं जहाँ latency औसत व्यक्ति को प्रभावित करती है या कभी-कभी लोगों को आश्चर्यचकित कर सकती है जब वे long distance WAN connection पर iSCSI जैसा कुछ असामान्य attempt करते हैं और अचानक latency एक unforeseen problem के रूप में उन्हें आश्चर्यचकित करती है।

वे स्थान जहाँ latency और throughput की interaction चौंकाने वाली और रोचक होने लगती है वह तब है जब हम electrical या optical data networks से physical ones पर जाते हैं। उद्योग में एक प्रसिद्ध quote है:

Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway.

यह बहुत अधिक latency के साथ huge bandwidth का एक महान demonstration है। शहर के पार पचास miles drive करने पर एक single stationwagon या SUV सैकड़ों petabytes data ले जा सकती है जो data rates तक पहुँचती हैं जो 10GB/s fiber बिल्कुल नहीं कर सकती। लेकिन पहला data packet arrive होने में लगभग एक घंटा लगता है। हम अक्सर इस प्रकार के network को discount कर देते हैं क्योंकि हम मान लेते हैं कि latency को लगभग 500ms से कम होना चाहिए। लेकिन यह हमेशा ऐसा नहीं होता।

Australia ने हाल ही में news में जगह बनाई जहाँ उन्होंने एक test किया यह देखने के लिए कि क्या SD card ले जाने वाला कबूतर, network throughput के terms में, regions के ISP से बेहतर प्रदर्शन कर सकता है — और कबूतर ISP से तेज़ निकला!

Computing performance के terms में हम अक्सर latency को इस हद तक ignore कर देते हैं कि हम इसे performance पर चर्चा करने के context के रूप में भी नहीं जानते। लेकिन low latency computing circles में इस पर बहुत सावधानी से विचार किया जाता है। System throughput आम तौर पर बहुत कम हो जाता है (यह सामान्य हो जाता है कि systems को केवल दस percent CPU utilization target करना है जबकि अधिक traditional systems नब्बे percent के करीब target करते हैं) जिसमें real time kernels, CPU affinity, processor pinning, cache hit ratios और lowered measuring जैसी अवधारणाएँ सभी का उपयोग एक system से सबसे अधिक total processing प्राप्त करने की कोशिश करने के बजाय सबसे तात्कालिक response प्राप्त करने पर ध्यान केंद्रित करने के लिए किया जाता है।

Computational perspective से low latency वांछित सामान्य स्थान critical controller systems (जैसे manufacturing controllers जहाँ एक millisecond की latency भी factory floor पर समस्याएँ पैदा कर सकती है) या financial trading systems में हैं जहाँ कुछ milliseconds की delay investment की कीमत बदल सकती है या products पहले ही बिक चुके होते हैं और उपलब्ध नहीं रहते। Latency के terms में speed अक्सर पैसा कमाने या खोने के बीच निर्णायक कारक होती है — एक single millisecond भी crippling हो सकता है।

तकनीकी रूप से audio और video processing systems को भी latency sensitive होना पड़ता है लेकिन अधिकांश modern computing systems में इतना spare processing overhead है और latency आम तौर पर इतनी कम है कि अधिकांश systems, यहाँ तक कि VoIP PBXs और conferencing systems, आज केवल बहुत कम ही processing side पर latency concerns के बारे में जागरूक होने की आवश्यकता के साथ कार्य कर सकते हैं (networking latency भी एक concern के रूप में कम और कम सामान्य होती जा रही है।) औसत system administrator या engineer आसानी से ऐसे career से गुजर सकता है जिसमें कभी किसी ऐसे system पर काम करने की जरूरत नहीं पड़ी जो latency sensitive हो या जिसके लिए इतना available overhead न हो कि कोई latency sensitivity छुपाई जा सके।

Speed को define करना, चाहे इसका अर्थ throughput, latency या कुछ और या दोनों का combination हो, IT के सभी पहलुओं में और जीवन में बहुत महत्वपूर्ण है। यह समझना कि वे अलग-अलग परिस्थितियों में हमें कैसे प्रभावित करते हैं और वे एक-दूसरे पर कैसे प्रतिक्रिया करते हैं — जहाँ throughput में सुधार latency की कीमत पर आता है या इसके विपरीत — और इन्हें जरूरत के अनुसार balance करना सीखना ताकि उन systems को बेहतर बनाया जा सके जिन पर हम काम करते हैं, बहुत मूल्यवान है।