जब प्रभावशाली प्रदर्शन सुधार मायने नहीं रखते

• प्रदर्शन optimization जटिल systems को समझने और product को बेहतर बनाने का शक्तिशाली तरीका है, लेकिन 10 गुना तेज़ परिणाम भी वास्तविक काम करने के तरीके या throughput को नहीं बदल सकते
• query response को 5–10 मिनट से घटाकर 30 सेकंड–1 मिनट कर देने पर भी, अगर यह उस लगभग 10 सेकंड की threshold से ऊपर है जिसमें इंसान इंतज़ार करते हुए ध्यान बनाए रखता है, तो महसूस होने वाला असर सीमित रहता है
• अगर काम दिन में 1 या 2 जैसे पूर्णांक units में बंधा हो, तो 25–50% सुधार पर्याप्त नहीं होता; यात्रा समय सहित हर काम 4 घंटे या कम होना चाहिए तभी दिन में 2 काम संभव हैं
• data pipeline में धीमा step upstream पर backpressure लगाता है, इसलिए किसी एक step के बहुत तेज़ होने पर भी जब तक सभी bottlenecks नहीं हटते, end-to-end throughput नहीं बढ़ सकता
• प्रदर्शन सुधार का मूल्यांकन अलग-अलग benchmarks से नहीं, बल्कि वांछित परिणामों के आधार पर करना चाहिए; अगर ध्यान बनाए रखने, काम की unit बढ़ाने, या कुल throughput जैसी बाधाएँ पार नहीं होतीं, तो बड़े सुधारों का भी वास्तविक असर छोटा रहता है

---

प्रदर्शन आँकड़े और वास्तविक परिणाम क्यों अलग हो जाते हैं

• प्रदर्शन पर काम करना systems को अधिक efficient बनाता है और ग्राहकों के लिए नई संभावनाएँ खोल सकता है, इसलिए यह संतोषजनक काम है
• यह scale और load में चल रहे जटिल systems के परस्पर interaction को अनुभवजन्य रूप से समझने में भी मदद करता है
• system के करीब काम करते हुए product और services को बेहतर बनाने के विचार निकलते हैं, जिनमें से कुछ का performance optimization से सीधा संबंध नहीं होता
• हालांकि “10 गुना तेज़”, “resources 50% कम” जैसे अच्छे दिखने वाले परिणाम भी, अगर छिपी बाधाओं को पार नहीं कर पाते, तो अपेक्षित बदलाव लाना मुश्किल होता है

10 सेकंड से ऊपर जाते ही user का ध्यान टूट जाता है

• एक नए database की query performance सुधारकर, पुराने database में सबसे महंगी query को 5–10 मिनट से घटाकर 30 सेकंड–1 मिनट करने का एक उदाहरण है
• यह परिणाम लगभग 10 गुना सुधार था, लेकिन user experience बदलने के लिए एक और बड़े सुधार की जरूरत थी
• human-computer interaction research में माना जाता है कि कोई व्यक्ति पूरे task पर ध्यान बनाए रखने की सीमा लगभग 10 सेकंड है
  • 0.1 सेकंड वह threshold है जिसे तुरंत feedback के रूप में महसूस किया जाता है
  • लगभग 1 सेकंड वह threshold है जिसमें काम का flow बना रहता है
  • लगभग 10 सेकंड वह threshold है जिसमें पूरे task पर ध्यान बनाए रहता है
  • progress indicator या estimated time जैसा feedback ध्यान बनाए रखने में मदद कर सकता है
• 30 सेकंड और 5 मिनट, दोनों 10 सेकंड से अधिक हैं, इसलिए user message check करता है, coffee लेने जाता है, बातचीत शुरू करता है, या दूसरे काम पर switch कर जाता है
• जब user कुछ मिनट या कुछ घंटों बाद लौटता है और UI पहले से load हो चुका होता है, तो वास्तविक wait time 30 सेकंड था या 5 मिनट, इससे काम करने के तरीके में बड़ा फर्क नहीं पड़ता
• उस project में अंततः कई queries को 10 सेकंड या कम तक घटाया गया, और कुछ queries जो पहले timeout के कारण असंभव थीं, वे भी संभव हो गईं
  • data query latency के साथ-साथ metadata query latency और webpage rendering time भी कुल performance सुधार के लिए महत्वपूर्ण थे
  • asynchronous IO और data aggregation सुधारों से एक और 10 गुना सुधार की संभावना बची है; ऐसा होने पर पहले कुछ मिनट लेने वाली queries 1 सेकंड से कम में लौट सकती हैं

दिन में 1 काम से 2 काम पर जाने की threshold

• एक project में manual work automation, अनावश्यक steps हटाने, कुछ parallelization, और बाद में asynchronous रूप से process किए जा सकने वाले steps को delay करने के जरिए पूरे process को कई घंटों से घटाकर भरोसेमंद रूप से 1 घंटे से कम कर दिया गया
• सुधार लगभग 25–50% था, लेकिन logistics constraints के कारण पूरा process नहीं बदला
• plumber, electrician, carpenter जैसे कामों की कल्पना की जा सकती है, जहां जगह book करके, वहाँ जाकर, काम पूरा करना होता है
  • अगर दिन में 8 घंटे काम होता है और एक जगह का काम 8 घंटे लेता है, तो 2–3 घंटे बचाने पर भी नई जगह जाकर नया काम खत्म करने का समय नहीं होता
  • यात्रा समय सहित हर काम 4 घंटे या कम न हो, तो दिन में 2 काम पूरे नहीं किए जा सकते
• ऐसी threshold पार करने से पहले, बीच के steps की efficiency improvements production बढ़ाने में नहीं बदलतीं
• performance पर focus करने की वजह से customer experience पर सीधे असर डालने वाले quality और reliability improvements भी साथ-साथ हो सकते हैं
  • production में breakthrough न बन पाने वाले छोटे performance improvements भी test environment में iteration speed बढ़ाकर feature development और defect resolution को तेज़ बना सकते हैं

backpressure वाली pipelines में bottlenecks

• बहुत-से business software infrastructure में vehicles, factory equipment, mobile phones, financial transactions जैसे कई sources के events process करने वाली data pipelines शामिल होती हैं
• events आमतौर पर durable log में store होते हैं, और downstream services उन्हें consume करके process करती हैं
• बड़े scale और high throughput के लिए log को partition करना पड़ता है, और downstream services batching, pipelining, parallelism, efficient memory allocation, dynamic scaling जैसी techniques इस्तेमाल करती हैं
• data pipeline के bottlenecks ढूँढना मुश्किल होता है क्योंकि system behavior आपस में जुड़ा होता है
  • धीमा step जानबूझकर upstream steps पर backpressure लगाता है
  • अगर कई bottlenecks हों, तो आखिरी bottleneck हटने तक कुल throughput नहीं बढ़ता
• pipeline को steps में बाँटना और हर step की performance characteristics और limits समझना अच्छी engineering practice है
• लेकिन किसी एक step को कई orders of magnitude तक सुधारने पर भी कुल throughput पर असर नहीं पड़ सकता
• throughput सुधार में अहम metric अलग-अलग steps का benchmark नहीं, बल्कि end-to-end throughput है

bottleneck खोजने का अनुभवजन्य तरीका

• ऐसे systems की dynamics और bottlenecks समझने के लिए pipeline के शुरुआती point से अनुभवजन्य रूप से verify करना उपयोगी है
• उदाहरण के लिए distributed log से events पढ़कर discard करने वाले step से शुरुआत करें
  • अगर केवल यह step ही target throughput तक नहीं पहुँचता, तो downstream steps को optimize करना समय की बर्बादी है
• database में प्रति सेकंड कितनी rows insert की जा सकती हैं जैसे downstream benchmarks भी महत्वपूर्ण हो सकते हैं, लेकिन analysis upstream से शुरू होना चाहिए
• जटिल systems और performance को समझने में simulations भी मूल्यवान तरीका हैं
  • Marc Brooker की Simple Simulations for System Builders
  • Try again: The tools and techniques behind resilient systems

प्रदर्शन सुधार का मानदंड वांछित परिणाम है

• performance work कठिन है, लेकिन यह जटिल systems को गहराई से समझने और बेहतर products बनाने की training भी है
• अगर इंसान का ध्यान पकड़े रखना है, तो लगभग 10 सेकंड के भीतर response देना होगा
• अगर पूरी work unit ही constraint है, तो केवल percentage improvement पर्याप्त नहीं है; दिन में 1 काम से 2 काम पर जाना संभव होना चाहिए
• backpressure वाली pipeline के throughput को maximize करने के लिए अक्सर एक-दो bottlenecks नहीं, बल्कि सभी bottlenecks हल करने पड़ते हैं
• अगर ऐसी constraints पार नहीं होतीं, तो 10 गुना स्तर का performance improvement भी वांछित परिणाम नहीं दे पाता

[GN⁺]

Lobste.rs की राय

• अगर आप किसी ऐसे चरण को दर्जनों गुना बेहतर करके निराश हो रहे हैं जिसका कुल throughput पर कोई असर नहीं है, तो यहाँ Amdahl's law का ज़िक्र करना सही होगा

  • सोचता हूँ कि क्या कंप्यूटर साइंस में ऐसे कई law names के संग्रह जैसा कुछ है
    लगातार नए laws सुनने को मिलते हैं, लेकिन वे इतने niche होते हैं कि अक्सर इस्तेमाल नहीं होते और फिर भूल जाता हूँ। इसका मतलब यह नहीं कि वे laws पीढ़ीगत ज्ञान के रूप में वैध या उपयोगी नहीं हैं

• शुरू में ही सवाल है कि कुल समय का बहुत छोटा हिस्सा लेने वाले भाग को optimize क्यों किया जा रहा था
  पता नहीं guidance खराब थी, या performance tools की कमी थी। बहुत कम लोग जानबूझकर लगभग बेअसर काम करना चाहते हैं; आम तौर पर कोई बड़ा मुद्दा छिपा होता है

  • मेरे हिसाब से ऐसा होने का एक रास्ता कुछ ऐसा है
    किसी समस्या को देखते समय sampling results में कोई खास function बड़ा दिखता है, और थोड़ी जाँच करने पर लगता है कि implementation को काफ़ी आसानी से बेहतर किया जा सकता है। लेकिन उस समय आप कोई और काम कर रहे होते हैं, इसलिए “बाद में करेंगे” कहकर टाल देते हैं
    बाद में वही आसान improvement याद आता है और आप शुरू करते हैं, लेकिन जब बदलाव उम्मीद से ज़्यादा जटिल हो जाता है, तब भी tunnel vision बन जाती है और puzzle हल करने की इच्छा में बहुत समय लग जाता है
    असल में वह performance issue मामूली ही था। उस समय जिस context को देख रहे थे उसमें वह proportionally बड़ा लगा होगा, या absolute time का कोई खास मतलब नहीं था, या bottleneck CPU नहीं बल्कि I/O था। यह एक तरह से खुद पर किया हुआ nerd sniping जैसा है
  • Google में एक बार pipeline के एक हिस्से को optimize करने का प्रस्ताव था, और कई लोगों ने समझाया कि वह हिस्सा कुल computation का 0.1% से कम है, इसलिए कुल लाभ भी परिभाषा के हिसाब से 0.1% से कम ही होगा
    फिर भी इसे नज़रअंदाज़ करके optimization किया गया, और जब कुल improvement 0.1% से कम निकली तो हैरानी हुई। domain knowledge हो तो intuitively भी वह हिस्सा महंगा नहीं था, लेकिन समय बर्बाद न हो इसलिए वास्तविक performance cost measure करने में भी मदद की गई
  • हो सकता है वे guesswork से चल रहे हों, या हमेशा लागू होने वाली best practices को internalize कर लिया हो, या सीमित स्थिति में देखी गई वास्तविक समस्या को बहुत ज़्यादा generalize कर दिया हो
    या benchmark ने भ्रमित किया हो। हर system production environment में हर method या process की cost आसानी से नहीं दिखाता
    ये सभी explanations अलग-अलग स्तर पर dysfunction जैसी हैं; कुछ अधिक व्यक्तिगत समस्या हैं और कुछ environment की समस्या के ज्यादा करीब हैं
  • संभावित कारण कुछ हैं
    1. कोई प्रतिभाशाली junior engineer जिसने problem solving तो सीखी है, लेकिन कौन-सी समस्या हल करने लायक है यह चुनना नहीं सीखा। वह end-to-end impact से परे, दिखी हर inefficiency पर हमला करता है। किस्मत अच्छी हो तो कोई सिखा देता है, वरना वह ऐसा senior engineer बनकर रुक जाता है जिसे PM को कड़ाई से control करना पड़ता है
    2. end-to-end performance ठीक से दिखाई नहीं देती। system में कहीं performance degradation है और management pressure डाल रहा है, लेकिन proper monitoring लाने का अधिकार नहीं मिला, इसलिए guesswork से कई components को छेड़ते हैं और उम्मीद करते हैं कि कोई एक सही निकले। फिर जब immediate fire बुझ जाती है तो फिर user features ship करने पर लौट जाते हैं
    3. अभी समस्या नहीं है, लेकिन जल्द समस्या बन जाएगी—इस डर से पहले ही fix करना। अगर आपका influence पर्याप्त है या आप overtime push कर सकते हैं, तो तुरंत दिखने वाला असर न होने पर भी आगे बढ़ते हैं। अच्छे engineers भी अगर मानते हैं कि यह future में important होगा तो इस पर political capital खर्च करते हैं, और कम अच्छे engineers सब कुछ जला डालते हैं
       3.1. अगर आप hyperscaler में काम करते हैं, तो user को बिल्कुल न दिखने वाली computation में 0.1% कटौती भी P&L पर beach house की कीमत जितना असर डाल सकती है
    4. challenge रोक नहीं पाना। आपको पता है कि असल में कुछ नहीं बदलेगा, लेकिन CRUD apps बनाते-बनाते ऊब गए हैं और blog में देखी चीज़ आज़माने का मौका मिल गया है। अर्थहीनता का बोझ कम करने के लिए खुद को nerd snipe करने जैसा है
  • आम धारणा के उलट, कई systems सिर्फ कुछ bottlenecks से नहीं बने होते
    आम programming practices खुद ही अक्सर overall धीमी होती हैं। उदाहरण के लिए, ढेर सारे pointers और general allocator के जरिए बहुत ज्यादा heap allocation वाला object-oriented code याद आता है। जहाँ भी fix करें, वह कुल समय का छोटा हिस्सा होता है, इसलिए सबसे खराब स्थिति में complete rewrite के अलावा हल नहीं होता। किस्मत अच्छी हो तो incremental rewrite कर सकते हैं
    अगर सिर्फ दो bottlenecks हों लेकिन दोनों एक-दूसरे से single-digit factor के भीतर हों, तो सबसे खराब bottleneck को पूरी तरह fix करने पर भी single-digit गुना improvement तक नहीं मिलेगा। कई मामलों में, जैसा लेख कहता है, meaningful gain पाने के लिए इससे कहीं ज्यादा आगे जाना पड़ता है
    साथ ही computers parallel चलने वाले distributed systems जैसे हैं। कुछ CPUs, GPU, disk, Ethernet वगैरह होते हैं, और process की speed pipeline के सबसे धीमे stage से limit होती है। उस stage को fix करें तो अगला सबसे धीमा stage limit करता है, और worst case में सबसे धीमे stages कई होते हैं, इसलिए केवल एक को fix करने से कोई फायदा नहीं होता
    फिर भी यह goodwill वाली explanation है; कभी-कभी लोग बस optimization game में फँसकर priorities खो देते हैं या गलती कर बैठते हैं

• भले ही users को पता न चले, software का computation time घटाना फिर भी अच्छा है
  क्योंकि इससे cost घट सकती है और scaling आसान हो सकती है

  • यह complexity cost पर निर्भर करता है
    code को तेज़ बनाने की कीमत पर अगर अत्यधिक complexity आ जाती है, तो maintainability को अलग भी रखें, long term में performance को नुकसान पहुँचाने वाले follow-on effects पैदा होते हैं। structure बदलने पर अब गैरज़रूरी हो चुका code बचा रहता है, और उसे समझने या हटाने के लिए पूरी complexity को पूरी तरह समझना पड़ता है
    “तेज़ हो जाएगा” वाला कारण complexity या maintainability concerns को नज़रअंदाज़ करने का blank cheque नहीं होना चाहिए

• मैं अभी मिलती-जुलती स्थिति में हूँ, और कई छोटे projects के जरिए 5 मिनट लगने वाली query को 30 सेकंड से कम पर ला रहा हूँ
  टीम से कहता हूँ कि long term में यह पर्याप्त नहीं है, लेकिन यह साफ़ improvement है और impact भी बड़ा है
  customer के नजरिए से wait time गुस्सा दिलाने वाले स्तर से सिर्फ annoying स्तर पर आ जाता है
  अभी focus per-user performance नहीं बल्कि overall performance है। 5 मिनट, 10 मिनट, 30 मिनट वाले दर्जनों processes को optimize करने से system के दूसरे हिस्सों के साथ होने वाला contention काफी घटता है। database को 10 मिनट तक hammer करना बहुत लंबा समय है, और आखिरकार सब कुछ तेज़ होता है, जिससे सभी को फायदा होता है