टीमों को डेस्कटॉप एक्जीक्यूशन गेटवे से कितनी लेटेंसी की अपेक्षा रखनी चाहिए?

डेस्कटॉप एक्जीक्यूशन गेटवे तभी उपयोगी है जब उसका मशीन विलंब इंटरैक्टिव काम की सहजता से कम रहे और अप्रूवल विलंब अलग से बताया जाए। मैं औसत, एक ही वार्म रन या ऐसे चार्ट के आधार पर रोलआउट मंजूर नहीं करूँगा जिसमें किसी व्यक्ति के Touch ID तक हाथ बढ़ाने का समय और सॉफ़्टवेयर के काम करने का समय मिला हो। आँकड़े साफ लग सकते हैं, लेकिन वे इंजीनियरिंग टीम को यह नहीं बता सकते कि गेटवे edit-test लूप को बाधित करेगा या नहीं।

सामान्य HTTP और पहले से जुड़े SSH काम के लिए, लक्ष्य डेवलपर Macs पर मैं शुरुआती अपनाने की सीमा p50 पर 25 ms से अधिक अतिरिक्त और p95 पर 75 ms से अधिक अतिरिक्त नहीं रखता। नए SSH कनेक्शन के लिए अलग और बड़ी सीमा रखें: p50 पर 50 ms से अधिक अतिरिक्त नहीं और p95 पर 150 ms से अधिक अतिरिक्त नहीं। इन्हें शुरुआती आवश्यकताएँ मानें, सार्वभौमिक स्थिरांक नहीं। टीम को अपने सीधे बेसलाइन, कॉल आवृत्ति, नेटवर्क और अनुभव परीक्षणों के आधार पर इन्हें कड़ा या ढीला करना चाहिए। नीचे का टेस्ट अच्छे माध्यिका के पीछे धीमी टेल को छिपाए बिना उस निर्णय के लिए जरूरी प्रमाण देता है।

परसेंटाइल एक ही ऑपरेशन को बताने चाहिए

p50 और p95 तभी अर्थपूर्ण हैं जब हर सैंपल एक ही सीमा का प्रतिनिधित्व करे। p50 माध्यिका है: देखी गई आधी कॉल इस समय पर या इससे पहले पूरी हुईं। p95 वह मान है जिस पर या उससे पहले 95 प्रतिशत कॉल पूरी हुईं। 200 क्रमबद्ध सैंपलों के रन में nearest-rank परिभाषा के अनुसार p95, 190वाँ मान है। इससे औसत में गुम होने के बजाय टेल में दस धीमे अवलोकन दिखते रहते हैं।

सीमा को उस समय से परिभाषित करें जब कॉलर ऑपरेशन शुरू करता है, उस समय तक जब उसे पूरा परिणाम मिल जाता है। प्रोग्रामिंग एजेंट इसी विलंब का अनुभव करता है। इसमें स्थानीय प्रक्रिया का काम, लक्ष्य तक ट्रांसपोर्ट, रिमोट एक्जीक्यूशन, जवाब का ट्रांसफर और रास्ते में आने वाला गेटवे का काम शामिल है। इसमें बेंचमार्क सेटअप और अनअटेंडेड ट्रैक में मानवीय पुष्टि शामिल नहीं है।

टीम अक्सर असमान सीमाओं की तुलना करती हैं। किसी सीधे HTTP चार्ट में curl का time_starttransfer हो सकता है, जबकि गेटवे चार्ट प्रक्रिया इनवोकेशन के आसपास कुल wall time लेता है। पहला शुरुआती response byte पर रुकता है, दूसरा परिणाम के serialize होकर लौटने के बाद। टेस्ट शुरू होने से पहले ही गेटवे हार जाता है। दोनों पथों पर कुल पूर्णता समय चुनें, फिर चरणों के समय को निदान वाले कॉलम के रूप में रखें।

यही नियम SSH पर भी लागू होता है। नया TCP कनेक्शन, SSH हैंडशेक, प्रमाणीकरण, रिमोट कमांड और डिस्कनेक्ट मिलकर एक ऑपरेशन हैं। मौजूदा multiplexed कनेक्शन पर भेजा गया कमांड दूसरा ऑपरेशन है। उन्हें अलग पंक्तियों में रिपोर्ट करें। मिलाने पर ऐसा वितरण बनता है जिसका p50 अधिकतर पुन: उपयोग को और p95 अधिकतर कनेक्शन सेटअप को बताता है। कोई सीमा भ्रमित समूह को ठीक नहीं कर सकती।

हर ऑपरेशन श्रेणी के लिए कम से कम ये कॉलम रिपोर्ट करें:

• सीधे पथ का p50 और p95 wall time
• ब्रोकरेज पथ का p50 और p95 wall time
• युग्मित सैंपलों से निकाला गया अतिरिक्त p50 और p95
• सैंपल संख्या, विफलताएँ और टाइमआउट संख्या
• होस्ट, नेटवर्क स्थिति, गेटवे संस्करण और अप्रूवल मोड

युग्मित अतिरिक्त लेटेंसी, दो मुख्य परसेंटाइल घटाने से अधिक महत्वपूर्ण है। सैंपल i के लिए उसी टेस्ट स्थिति में delta_i = brokered_i - direct_i निकालें, फिर डेल्टा का p50 और p95 लें। p95(brokered) - p95(direct) उपयोगी संदर्भ है, लेकिन वह p95 ओवरहेड नहीं है और नेटवर्क स्पाइक व गेटवे काम के बीच संबंध भी छिपा सकता है।

बेंचमार्क अनुबंध सुविधाजनक नतीजों से बचाता है

बेंचमार्क चलाने से पहले उसका अनुबंध लिखें, क्योंकि लगभग हर अनजाना अनुकूलन सवाल ही बदल देता है। Mac मॉडल और macOS संस्करण, पावर की स्थिति, थर्मल स्थिति, नेटवर्क पथ, लक्ष्य होस्ट क्षेत्र, HTTP प्रोटोकॉल, SSH cipher negotiation, payload आकार, response आकार, timeout, concurrency और कनेक्शन reuse दर्ज करें। बैकग्राउंड लोड डेवलपर मशीन जैसा रखें। ऐसा बिलकुल साफ लैपटॉप जिसमें हर editor और build प्रक्रिया बंद हो, सिर्फ प्रयोगशाला का सवाल हल करता है।

एक स्थानीय लक्ष्य और एक यथार्थवादी रिमोट लक्ष्य लें। स्थानीय लक्ष्य मशीन ओवरहेड दिखाता है क्योंकि नेटवर्क का उतार-चढ़ाव बहुत कम है। रिमोट लक्ष्य दिखाता है कि असली ट्रांसपोर्ट विलंब के बीच वह ओवरहेड अब भी मायने रखता है या नहीं। 3 ms की loopback request में 40 ms जोड़ने वाला गेटवे, 300 ms की रिमोट कॉल में उतना ही जोड़ने वाले गेटवे से बहुत अलग महसूस होगा, फिर भी दोनों नतीजे रिपोर्ट में होने चाहिए।

एक मिश्रित suite के बजाय ऑपरेशन श्रेणियाँ बनाएँ। न्यूनतम उपयोगी सेट है: पुन: उपयोग कनेक्शन पर छोटा HTTP response, नए कनेक्शन पर छोटा HTTP response, true चलाने वाला नया SSH कनेक्शन और पहले से उपलब्ध कनेक्शन पर SSH कमांड। टीम के प्रोग्रामिंग वर्कफ़्लो से एक प्रतिनिधि payload और एक प्रतिनिधि response जोड़ें। लेटेंसी टेस्ट के लिए destructive API या प्रोडक्शन SSH होस्ट का उपयोग न करें।

ऐसा warmup चलाएँ जो कभी सैंपल सेट में न आए। फिर हर श्रेणी में कम से कम 200 मापी गई कॉल लें और सीधे व ब्रोकरेज वाले क्रम को बारी-बारी से चलाएँ। अगर हर सीधी कॉल पहले चले, तो बाद का थर्मल बदलाव, नेटवर्क बदलाव, DNS cache या server cache गेटवे ओवरहेड बन जाएगा। यादृच्छिक क्रम स्वीकार्य है, पर कड़ा alternation जाँचना आसान है।

इंटरैक्टिव बेंचमार्क में concurrency एक रखें। टूल परिणाम की प्रतीक्षा करता एजेंट क्रमिक उपयोगकर्ता है। अगर कई एजेंट गेटवे साझा करेंगे तो दूसरा load test चलाएँ, लेकिन उसे capacity work नाम दें। 20-way टेस्ट queueing सीमा दिखा सकता है, एकल कॉल लेटेंसी परिणाम का स्थान नहीं ले सकता।

विफलताओं को रिपोर्ट में रखें। टाइमआउट को उसके बीते हुए timeout मान के साथ विफलता लिखें और परसेंटाइल के साथ विफलता दर प्रकाशित करें। चुपचाप त्रुटियाँ हटाने पर उस पथ को इनाम मिलता है जो जल्दी विफल होता है या अपनी सबसे धीमी कॉल छोड़ देता है। अगर किसी पथ में इतनी विफलताएँ हैं कि उसका p95 अस्थिर है, तो मिलीसेकंड पर बहस रोकें और पहले विश्वसनीयता ठीक करें।

HTTP को उसका अर्थ बदले बिना मापें

सीधे और ब्रोकरेज HTTP के लिए वही method, URL, headers, body, timeout और response consumption लें। क्रेडेंशियल स्रोत अलग हो सकता है, क्योंकि क्रेडेंशियल अलगाव गेटवे का उद्देश्य है, लेकिन सर्वर को दोनों वैरिएंट से समान अर्थ वाली request दिखनी चाहिए। टाइमिंग डेटा लेने से पहले पुष्टि करें कि दोनों को एक जैसा status, चुने हुए response headers और body hash मिलते हैं।

curl अपने documented write-out variables में उपयोगी चरण घड़ियाँ देता है। time_connect नेटवर्क कनेक्शन पूरा होने पर समाप्त होता है, time_appconnect में TLS हैंडशेक शामिल है, time_starttransfer पहले response byte तक जाता है और time_total पूर्णता तक। ये मान regression खोजने में मदद करते हैं, लेकिन कॉलर wall time तुलना की सीमा बना रहता है क्योंकि broker curl से पहले या upstream response के बाद काम कर सकता है।

यह सीधा probe बिना लिंक जोड़े या progress output parse किए, सेकंड में चार फ़ील्ड प्रिंट करता है:

curl -sS -o /dev/null -w '%{time_connect} %{time_appconnect} %{time_starttransfer} %{time_total}
' -H "$AUTH_HEADER" "$ENDPOINT"

युग्मित माप के लिए पूरी सीधी invocation DIRECT_CMD में और पूरी गेटवे invocation BROKER_CMD में रखें। यह runner उनका क्रम बदलता है, monotonic clock का उपयोग करता है, विफलताएँ बचाए रखता है और हर अवलोकन पर एक JSON object निकालता है। यह जानबूझकर हर कमांड को argument vector मानता है, ताकि shell operators और expansions बेंचमार्क में न आ जाएँ।

import json
import os
import shlex
import subprocess
import time

samples = int(os.environ.get("SAMPLES", "200"))
timeout = float(os.environ.get("TIMEOUT", "10"))
commands = {
    "direct": shlex.split(os.environ["DIRECT_CMD"]),
    "brokered": shlex.split(os.environ["BROKER_CMD"]),
}

for n in range(10):
    label = "direct" if n % 2 == 0 else "brokered"
    subprocess.run(commands[label], stdout=subprocess.DEVNULL,
                   stderr=subprocess.DEVNULL, timeout=timeout)

for n in range(samples):
    order = ("direct", "brokered") if n % 2 == 0 else ("brokered", "direct")
    for label in order:
        started = time.monotonic_ns()
        try:
            result = subprocess.run(commands[label], capture_output=True,
                                    timeout=timeout)
            ok = result.returncode == 0
            code = result.returncode
        except subprocess.TimeoutExpired:
            ok = False
            code = None
        elapsed_ms = (time.monotonic_ns() - started) / 1_000_000
        print(json.dumps({"pair": n, "path": label, "ms": elapsed_ms,
                          "ok": ok, "code": code}, separators=(",", ":")))

आउटपुट को JSON Lines फ़ाइल में कैप्चर करें। लेटेंसी निकालने से पहले timed loop के बाहर success codes और response hashes मिलाएँ। कम डेटा लौटाने वाली ब्रोकरेज request तेज दिखेगी। यदि सीधी request redirects follow करे और broker न करे, तो दोनों अलग काम माप रहे हैं।

कनेक्शन reuse को स्पष्ट रूप से नियंत्रित करना चाहिए। अगर एजेंट प्रोटोकॉल और गेटवे upstream HTTP कनेक्शन बनाए रखते हैं, तो उसकी तुलना ऐसे सीधे client से करें जो कनेक्शन रखता हो। हर सीधे सैंपल के लिए नया curl process चलाने से कनेक्शन reuse छूट सकता है और ब्रोकरेज पथ अनुचित रूप से अच्छा दिख सकता है। प्रक्रिया-आधारित टेस्ट में या तो दोनों तरफ नए कनेक्शन बाध्य करें या दो छोटे persistent clients बनाएँ। अपनी पसंद प्रकाशित करें।

SSH में cold और reused माप चाहिए

छोटे रिमोट कमांड में SSH सेटअप अक्सर सबसे अधिक समय लेता है, इसलिए एक SSH परसेंटाइल बहुत कम बताता है। OpenSSH client manual में ControlMaster और ControlPersist के जरिए connection sharing का विवरण है। sharing चालू होने पर बाद के sessions transport setup और authentication दोहराने के बजाय मौजूदा नेटवर्क कनेक्शन उपयोग कर सकते हैं। यह वैध प्रोडक्शन अनुकूलन है, पर दोनों पथों को इसे उपयोग करने का समान अवसर मिलना चाहिए।

नए कनेक्शन की श्रेणी के लिए sharing बंद करें, true जैसा सुरक्षित कमांड चलाएँ और disconnect करें। समर्पित टेस्ट होस्ट पर सीधा कमांड ऐसा दिख सकता है:

ssh -F /dev/null -o BatchMode=yes -o ControlMaster=no -o ConnectTimeout=10 "$TEST_HOST" true

युग्मित ब्रोकरेज कॉल के लिए गेटवे की सामान्य SSH कार्रवाई उपयोग करें, उसी host, user और remote command के साथ। गेटवे को ऐसे कृत्रिम setup से न चलाएँ जिसका एजेंट कभी उपयोग नहीं करेगा। इसके बजाय सीधे पथ को गेटवे के documented connection behavior के अनुरूप बनाएँ या नतीजे में वास्तु संबंधी अंतर घोषित करें।

reused श्रेणी के लिए warmup से पहले कनेक्शन स्थापित करें और sampling के दौरान केवल remote true कमांड चलाएँ। मान लेने के बजाय reuse सत्यापित करें। OpenSSH verbose diagnostics बता सकते हैं कि client control socket से संपर्क करता है या नहीं। गेटवे को इतना diagnostic timing या logs देना चाहिए कि पता चल सके कि उसने transport reuse किया या नहीं। अगर reuse सिद्ध नहीं किया जा सकता, तो श्रेणी को "अज्ञात कनेक्शन स्थिति" नाम दें और किसी ज्ञात reused पथ से उसकी तुलना न करें।

फिर एक वास्तविक, गैर-विनाशकारी कार्य के साथ दोहराएँ, जैसे कोई छोटी स्थिर फ़ाइल पढ़ना या टेस्ट service से status पूछना। true कनेक्शन और एक्जीक्यूशन plumbing को अलग करता है, लेकिन output transfer, decoding या result limits को नहीं परखता। फ़ाइल की सामग्री स्थिर रखें और लौटे bytes का hash लें।

SSH authentication भी तुलना बदल देता है। सीधे baseline को सुविधाजनक बनाने भर के लिए एजेंट को private key नहीं मिलनी चाहिए। सीधे पथ को समान नेटवर्क access वाले isolated harness में चलाएँ और उसके credential exposure को benchmark fixture मानें, स्वीकृत design नहीं। लेटेंसी mediation की लागत बताती है। यह तय नहीं करती कि autonomous process को key देना स्वीकार्य है या नहीं।

गेटवे के अपने काम के आसपास instrumentation करें

बाहरी stopwatch उपयोगकर्ता को दिखने वाला परिणाम साबित करती है, जबकि अंदरूनी timestamps उसका कारण बताते हैं। receipt, request validation पूरा होने, authorization decision पूरा होने, credential operation पूरा होने, upstream dispatch, पहला upstream byte, upstream completion, audit commit और result delivery पर monotonic timestamps जोड़ें। secrets या request bodies नहीं, durations या साझा trace identifier रिकॉर्ड करें।

ये timestamps अतिरिक्त मशीन विलंब को उन हिस्सों में बाँटते हैं जिन पर टीम कार्रवाई कर सकती है:

• स्थानीय protocol parsing और serialization
• authorization lookup और कोई queue wait
• vault या credential operation
• upstream client setup और connection acquisition
• audit persistence और result return

अलग प्रक्रियाओं के wall clock timestamps की तुलना न करें, जब तक माप डिज़ाइन clock differences को नहीं संभालता। एक Mac पर हर प्रक्रिया की monotonic clock durations के लिए स्थिर है, लेकिन अलग runtimes में उनके origins मेल नहीं खा सकते। सबसे सुरक्षित डिज़ाइन में हर component अपना duration देता है और records को opaque test identifier से जोड़ा जाता है।

अगर गेटवे सफलता बताने से पहले कार्रवाई रिकॉर्ड करने का वादा करता है, तो audit work मापी गई सीमा में रहना चाहिए। response के बाद write ले जाने से गारंटी कमजोर करके बेंचमार्क जीता जा सकता है। batching उचित हो सकती है, पर प्रकाशित durability point प्रोडक्शन जैसा होना चाहिए। टेस्ट उस उत्पाद को मापे जिसे लोग चलाएँगे, जिसमें सामान्य journal और security controls चालू हों।

चरण डेटा संदिग्ध हिस्सा बताए तभी profile करें। अगर response size के साथ p50 बढ़े, तो copies और serialization देखें। अगर p95 बढ़े और p50 स्थिर रहे, तो locks, queue waits, audit flushes, connection pool misses और operating system scheduling देखें। शांत माध्यिका कॉल का CPU profile शायद ही tail stall समझाता है।

बेंचमार्क को observer cost से भी बचाएँ। terminal पर विस्तृत logging blocking I/O जोड़ सकती है। छोटे records किसी फ़ाइल या in-memory buffer में लिखें, diagnostic events चालू रखकर एक बार मापें और पुष्टि करें कि अंतर नगण्य है। जहाँ संभव हो, सीधे और ब्रोकरेज runs में diagnostic mode एक जैसा रखें।

मानवीय पुष्टि का service level अलग है

confirmation समय तब शुरू होता है जब approval card दिखता है और तब समाप्त होता है जब निर्णय blocked call तक पहुँचता है। यह गेटवे की मशीन लेटेंसी नहीं है। इसे automatic calls के साथ मिलाने से p95 hand position, ध्यान, screen state और interruption से तय होगा। यह वर्कफ़्लो का महत्वपूर्ण माप हो सकता है, लेकिन यह बताता है कि approval काम में फिट बैठता है या नहीं, execution path कुशल है या नहीं यह नहीं।

सुरक्षित actions के लिए तीन distributions रिपोर्ट करें। पहला, prompt से पहले का गेटवे मशीन समय। दूसरा, दिखने वाले prompt से निर्णय तक का समय। तीसरा, निर्णय के बाद result delivery तक का मशीन समय। इनके साथ end-to-end आंकड़ा दिख सकता है, बशर्ते कोई भी उसे transport overhead के निदान में न उपयोग करे।

clicks automate करके उसे human latency न कहें। automation presentation और decision plumbing माप सकता है, जो machine buckets में जाना चाहिए। मानवीय अध्ययन में सहमति देने वाले प्रतिभागी, परिभाषित कार्य और ऐसे event timestamps चाहिए जो संवेदनशील input कैप्चर न करें। प्रतिभागियों की संख्या और उन्हें prompt की अपेक्षा थी या नहीं, रिपोर्ट करें। scripted test में अपेक्षित Touch ID confirmation, असली प्रोग्रामिंग के दौरान अनपेक्षित approval से तेज होगी।

approval modes के लिए भी अलग पंक्तियाँ चाहिए। पहले से authorized session में अनुमत कार्रवाई, प्रक्रिया को authorize करने के लिए पूछने वाली पहली कॉल और हर-कॉल confirmation, डिज़ाइन के अनुसार अलग पथ हैं। इन्हें मिलाने पर परिणाम सैंपल में उनकी संयोगवश आवृत्ति पर निर्भर हो जाता है।

उपयोगी workflow budget interruption को बताता है, यह दिखावा नहीं करता कि हर approval 100 ms से कम होना चाहिए। उदाहरण के लिए, गेटवे तक कॉल पहुँचने के 150 ms के भीतर p95 पर card दिखना अनिवार्य करें। फिर टीम के वास्तविक उपयोग को देखने तक human decision time को pass या fail लक्ष्य के बिना मापें। बाद में abandonment, गलत approvals और task disruption के आधार पर लक्ष्य तय करें। तेज approval खराब है अगर card सही चुनाव के लिए जरूरी identity या action detail छिपा दे।

चार्ट बनाने से पहले डेल्टा निकालें

result calculator को observations pair करने चाहिए, latency distribution से अधूरे pairs हटाने चाहिए और उन अधूरे pairs को failures के रूप में रिपोर्ट करना चाहिए। इससे सफल सीधी कॉल की तुलना अगले ब्रोकरेज कॉल से नहीं होगी जबकि उसका असली partner timeout हो गया था। runner का pair number join field के रूप में रखें।

हर जगह एक ही percentile definition उपयोग करें। nearest-rank method मानों को sort करता है और एक से शुरू होने वाले ranks में ceil(p * n) rank चुनता है। libraries interpolated percentiles दे सकती हैं जो ऐसा मान लौटाएँ जो कभी देखा ही नहीं गया। कुछ विश्लेषण में interpolation सही है, पर notebook और dashboard में तरीके बदलने से सीमा के आसपास बेकार बहस होती है। रिपोर्ट में तरीका लिखें।

यह छोटा calculator पहले वाले runner से निकली JSON Lines लेता है। यह direct time, brokered time और paired added time के लिए counts तथा nearest-rank p50 और p95 प्रिंट करता है:

import json
import math
import sys

rows = [json.loads(line) for line in sys.stdin if line.strip()]
by_pair = {}
failures = {"direct": 0, "brokered": 0}

for row in rows:
    if not row["ok"]:
        failures[row["path"]] += 1
        continue
    by_pair.setdefault(row["pair"], {})[row["path"]] = row["ms"]

direct = []
brokered = []
deltas = []
for pair in sorted(by_pair):
    values = by_pair[pair]
    if "direct" not in values or "brokered" not in values:
        continue
    direct.append(values["direct"])
    brokered.append(values["brokered"])
    deltas.append(values["brokered"] - values["direct"])

def percentile(values, fraction):
    ordered = sorted(values)
    rank = max(1, math.ceil(fraction * len(ordered)))
    return ordered[rank - 1]

result = {"complete_pairs": len(deltas), "failures": failures}
for name, values in (("direct", direct), ("brokered", brokered),
                     ("added", deltas)):
    result[name] = {
        "p50_ms": percentile(values, 0.50),
        "p95_ms": percentile(values, 0.95),
        "max_ms": max(values),
    }
print(json.dumps(result, separators=(",", ":")))

आउटपुट संरचना जानबूझकर सरल है: complete_pairs, हर पथ के failure counts और हर distribution के लिए p50_ms, p95_ms और max_ms वाला block। यदि टीम पहले से confidence intervals उपयोग करती है तो उन्हें जोड़ें, लेकिन interval को raw tail inspection की जगह न लेने दें। कोई percentile अलग runs में इसलिए बदल सकता है कि system बदला या sampling अलग रही। कच्ची rows बताती हैं कि कौन-सा कारण सही है।

negative deltas वैध हैं। वे तब आ सकते हैं जब broker उस connection को reuse करे जिसे direct command फिर से खोलता है, या जब सामान्य network noise pair के brokered सदस्य के पक्ष में जाए। उन्हें शून्य पर clamp न करें। इसके बजाय अनुचित connection setup ठीक करें या paired distribution में variance रहने दें। clamping हर percentile को ऊपर की ओर झुका देता है और calculation का audit कठिन बनाता है।

डेटा में पूरा precision रखें और केवल presentation values को round करें, बेहतर हो कि एक decimal millisecond तक। threshold evaluation unrounded number से होनी चाहिए। 75.0 ms के रूप में रिपोर्ट किया गया मान 75 ms gate से थोड़ा ऊपर हो सकता है, अगर तुलना से पहले formatting हुई हो।

टेल लेटेंसी बताती है कि भरोसा कहाँ कम होता है

इंटरैक्टिव प्रोग्रामिंग में अनियमित देरी, स्थिर छोटे अतिरिक्त समय से ज्यादा नुकसान करती है। डेवलपर हर tool call पर आने वाले 15 ms अतिरिक्त समय के अनुकूल हो सकता है। अनियमित 800 ms का pause एजेंट को टूटा हुआ महसूस कराता है, खासकर जब कई calls क्रम से हों। इसलिए p95 सजावटी chart के बजाय अपनाने की आवश्यकता है।

कच्चे tail observations देखें। लिखें कि क्या हर observation HTTP connection miss, SSH handshake, vault unlock, audit flush, app wake, CPU pressure या network spike के साथ आया था। किसी outlier को केवल इसलिए न हटाएँ कि आप उसका कारण बता सकते हैं। अगर प्रोडक्शन में वह स्थिति होगी तो उसे distribution में रहना चाहिए। सिर्फ सिद्ध test fault हटाएँ, मूल डेटा बचाकर रखें और exclusion rule प्रकाशित करें।

engineering के दौरान p99 मदद कर सकता है, लेकिन छोटे samples में वह noisy होता है। 200 calls में p99 लगभग दो सबसे धीमे observations पर टिका होता है। मैं अपनाने के लिए p50 और p95 अनिवार्य करता हूँ, फिर failure patterns के लिए maximum और raw tail rows देखता हूँ। इंटरैक्टिव gate पास होने के बाद लंबा overnight run p99 के काम में सहायक हो सकता है।

warm और cold states दिखते रहने चाहिए। यदि users को app launch या vault unlock मिलता है, तो उसे अलग operation के रूप में मापें, steady calls में न मिलाएँ। इसी तरह Mac sleep और wake recovery अलग रिपोर्ट करें। हमेशा चलने वाला desktop app warmup के बाद शानदार दिख सकता है और फिर भी lunch के बाद पहली action को खराब संभाल सकता है।

sequence cost भी निर्णय का हिस्सा है। यदि किसी प्रोग्रामिंग task में बारह serial calls होती हैं, तो अतिरिक्त देरी जमा होती है। captured और scrubbed action sequence चलाने से उन costs का पता चल सकता है जो isolated requests में नहीं दिखते, जैसे pool churn या session बढ़ने के साथ धीमा होता journal। अलग-अलग operation distributions रखें, फिर secondary measure के रूप में task completion delta जोड़ें।

इंटरैक्शन लागत से gate तय करें

गेटवे तब पास होता है जब अतिरिक्त machine delay absolute terms में भी कम हो और direct path की तुलना में भी कम हो। प्रतिनिधि load पर मौजूदा desktop के लिए मैं इन चार सीमाओं से शुरुआत करता हूँ:

• reuse वाला HTTP: p50 पर 25 ms और p95 पर 75 ms
• नया connection वाला HTTP: p50 पर 30 ms और p95 पर 100 ms
• reused connection वाला SSH: p50 पर 25 ms और p95 पर 75 ms
• fresh connection वाला SSH: p50 पर 50 ms और p95 पर 150 ms

relative check तब लागू करें जब direct p95 कम से कम 100 ms हो। 3 ms की loopback call पर 20 प्रतिशत नियम एक millisecond से कम की अनुमति देता है और अधिकतर noise मापता है। धीमी remote call पर सिर्फ absolute limit ऐसा implementation स्वीकार कर सकती है जो direct time का बड़ा हिस्सा जोड़ती है। दोनों checks अलग परिस्थितियों को संभालते हैं।

failure rate को direct से बस थोड़ी, घोषित tolerance तक ही अधिक होने दें और गेटवे से हुआ कोई timeout अपने-आप investigation बने। 10 ms की median जीत के लिए मैं reliability का सौदा नहीं करूँगा। सही result equivalence और अपेक्षित audit durability भी अनिवार्य करें। तेज path जो response बदल दे या उसे बाद में record करे, वह अलग और अधिक गंभीर टेस्ट में विफल है।

यह gate उस सबसे धीमी supported Mac श्रेणी पर चलाएँ जिसे टीम सचमुच उपयोग करती है, केवल bench पर नए machine पर नहीं। power पर और representative editor तथा build load के साथ दोहराएँ। remote targets के लिए अलग-अलग दिनों या network periods में तीन runs अनिवार्य करें। यह सांख्यिकीय रस्म नहीं है, बल्कि किसी एक अनुकूल network window को product promise बनने से रोकता है।

टीम provisional numbers को blinded perception test से समायोजित कर सकती है। mock gateway में निश्चित delays डालें, सामान्य agent task फिर चलाएँ और developers से delay बताए बिना interruption को rate करने को कहें। जो सबसे छोटी देरी लगातार शिकायत कराए, उसे चुनें और margin के साथ p95 limit उसके नीचे रखें। 150 ms fresh SSH allowance तभी रखें जब direct handshake पहले ही हावी हो और पूरा task तत्काल लगे।

अगर कोई सामान्य operation p95 limit चूकता है, तो rollout अस्वीकार करें, भले ही combined chart पास हो। weighted aggregate में अक्सर आने वाली तेज HTTP calls धीमी SSH actions को दबा सकती हैं। operation class के आधार पर मंजूरी दें, फिर captured task sequence देखकर पुष्टि करें कि कई स्वीकार्य अतिरिक्त समय मिलकर अस्वीकार्य pause नहीं बना रहे।

अपनाना वापस लेने योग्य और प्रमाण-आधारित रखें

अपनाने की शुरुआत canary group और दर्ज rollback condition के साथ होनी चाहिए। benchmark script, fixtures, gateway configuration और result calculator को version control में freeze करें। screenshots के बजाय raw observations सहेजें। निर्णय की समीक्षा करने वाला हर व्यक्ति percentiles फिर से निकाल सके और हर failure देख सके।

Sallyport के लिए यही harness उसके HTTP और SSH channels से चलाएँ। vault, session authorization, per-call setting और audit behavior को ठीक उसी तरह configure करें जैसा प्रस्तावित deployment में होगा। उसके encrypted hash-chained audit log को sp audit verify से offline जाँचा जा सकता है। benchmark के बाद इसे चलाएँ, ताकि latency report और integrity check एक ही calls के बारे में हों।

तभी आगे बढ़ें जब हर operation class representative Macs पर पास हो, result hashes मिलें, audit verification सफल हो और developers पूरा task replay स्वीकार करें। canary के दौरान direct escape path रखें, पर हर उपयोग और उसका कारण दर्ज करें। अगर लोग p95 के अनियमित लगने पर गेटवे को bypass करते हैं, तो benchmark ने workflow नहीं पकड़ा। rollout बढ़ाने से पहले measurement ठीक करें।