दो वास्तविक परीक्षाएँ, एक scale-in गलती और planning model। अंतिम समीक्षा observations, extrapolation, operating cost और बचे tests अलग रखती है।
लेखक
Anichur Rahaman
7 October 2026 को दो परीक्षाएँ लगातार चलीं। Case record में पहली के 661 starts और 638 submissions, दूसरी के 439 starts और 425 submissions हैं। बीच में pool minimum घटा तो serving node अपेक्षित drain के बिना हट गया और दो मिनट में लगभग 360 requests असफल हुईं। काम करता service और यह failure, दोनों परिणाम का हिस्सा हैं।
NovaCommerce course और exam platform का अनाम नाम है। अंतिम भाग September–October observations रखता है, प्रकाशित arithmetic फिर गिनता है और अप्रमाणित बातें स्पष्ट करता है। यह नया load test या StoreConsole benchmark नहीं।
25 September को IP-keyed limiter, 6 October run में Valkey connection failures और tested request mix में backend CPU saturation मिली। कारण अलग थे, सुधार भी अलग। कुछ capacity pressure में servers मदद करते हैं; identity या shared service की गलती का विकल्प नहीं।
Records में frontend लगभग 356 requests/s, p95 0.05 s और zero reported errors; 5 October GET autoscale run लगभग 750 requests/s, zero server errors/timeouts मगर करीब 4% HTTP 429; तथा 25–500 ramp में zero application errors मगर 143 load-balancer errors हैं। Mix और scope अलग हैं। इनके सबसे अच्छे आँकड़े जोड़कर एक successful throughput claim न बनाएँ।
बाद के guarded rollout में हर दो seconds पर 219 probes, zero errors थे। उपयोगी sampling है, हर request, write या long connection बचने का प्रमाण नहीं। Business-flow test में authenticated answer acceptance, durable receipts, safe retry और final results चाहिए; केवल HTTP status या cached homepage नहीं।
638/661 लगभग 96.5%; 425/439 लगभग 96.8%। ये submission proportions हैं, availability percentages नहीं। Submission न करने के कई कारण हो सकते हैं; count हर कमी को technical failure या zero data loss सिद्ध नहीं करता।
Minute logs में backend peak करीब 69 requests/s, provider two-minute aggregation में 63 था। Reported average पर pool CPU peak 47%, एक node एक मिनट के लिए 86% था। MySQL max CPU 24.5%, average 13.4%; worker max 46%, zero recorded failed jobs। Windows और denominators स्पष्ट रखें। Zero failed jobs का अर्थ कोई pending या lost work नहीं होना नहीं है।
पुराना CPU estimate लगभग 59 ms/request था। 63 requests/s पर 3.717 CPU-seconds/s; आठ vCPU से भाग देने पर करीब 46.5%। 47% के पास होना उन assumptions का consistency check है, causation या linear scale का प्रमाण नहीं। Scale-in incident ने readiness, per-node load और retirement के अलग evidence की ज़रूरत दिखाई। Exam-hours runbook मानवीय control था, enforced रोक नहीं।
पुराना model प्रति node 50 backend requests/s, baseline 30 requests/s, imbalance factor 1.3, प्रति छात्र 15 opening requests और मौजूद रहने पर 0.025 requests/s मानता था। समान request mix और agreed latency के लिए 50 hypothesis है, universal safe limit नहीं।
N healthy nodes पर student budget N×50÷1.3−30 requests/s। 600-second join में हर छात्र 15÷600+0.025=0.05 requests/s; 120 seconds में 0.15। चार nodes के लिए (4×50÷1.3−30)÷0.05≈2,477; teaching table इसे नीचे 2,400 करती है। यह fluid average model है; bursts, uneven arrivals और pauses सीमा पार करा सकते हैं।
1.3 divisor planning factor है, 30% idle capacity या automatic node-failure coverage नहीं। एक node खोने का model अलग बनाएँ। कुछ nodes के observed tests से ऊपर की rows extrapolation हैं, certified student capacity नहीं। PDF uploads, worker queues, database contention और provider limits इसके बाहर हैं। कम database CPU से 450 requests/s ceiling या छह गुना headroom सिद्ध नहीं।
| Healthy backend nodes | Model budget requests/s | 600-second join: rounded students | 120-second join: rounded students |
|---|---|---|---|
| 2 | ≈77 | 900 | 300 |
| 4 | ≈154 | 2,400 | 800 |
| 6 | ≈231 | 4,000 | 1,300 |
ऐतिहासिक design में independent frontend/backend pools, हर एक minimum दो और maximum दस; primary/standby MySQL, shared Valkey, अलग PostgreSQL/pgvector, object storage और OpenSearch में backend logs थे। एक fixed worker queues, scheduler, WebSockets और SMS चलाता था। वह single failure point था; frontend log shipping और worker standby planned थे।
Replication, stateless web nodes और images कुछ recovery paths सुधारते हैं। वे हर dependency redundant या regional failure, bad deployment, unauthorized access अथवा गलत deletion से सुरक्षा नहीं देते। Write fencing और restore अलग test हों। नई writes के बाद frozen old data current rollback नहीं; image rollback को भी schema, sessions और queued payloads की compatibility चाहिए।
ऐतिहासिक monthly web items $272 हैं: backend $112 +frontend $56 +worker $56 +दो balancers $48। Data/logs $709: MySQL $389 +Valkey $240 +PostgreSQL $60 +OpenSearch $20। Snapshots $5 और Spaces base $5 के साथ $991, variable usage से पहले। पुराना “लगभग $990” rounding था, exact invoice नहीं।
पहले के $416 में powered-off recovery Droplets समेत web tier था, पुराना full stack नहीं। Scope और service assumptions समान हों तभी $416 से $272 तुलना करें, नए combined $991 से नहीं। Staff, support, tax, AI/SMS, overages और temporary rollout/peak capacity बाहर हैं। यह total ownership cost या current quote नहीं।
Current plans और account eligibility जाँचें। भाग 3 के MySQL Standard बदलाव पुराने pair को unchecked 2026 buying recipe नहीं रहने देते। Reliability पर बड़ा budget उचित हो सकता है, लेकिन savings claim के लिए comparable service और पूरा operating model चाहिए।
| ऐतिहासिक monthly group | Listed subtotal | Scope |
|---|---|---|
| Web tier | $272 | 2 backend +2 frontend +worker +2 balancers |
| Data और logs | $709 | MySQL +Valkey +PostgreSQL +OpenSearch |
| Snapshots/storage base | $10 | $5 +$5; usage अलग |
| Listed combined base | $991 | Usage, staff, tax और अन्य services से पहले |
Record में formal multi-hour soak और full mixed write-path load test planned थे। दो घंटे exam observation controlled soak नहीं। 24 घंटे local writes न दिखना memory leak, connection growth या बढ़ती queue को नहीं नकारता। इन्हें चुपचाप passed न लिखें।
अगले बड़े event से पहले successful-answer और latency thresholds तय करें; representative identities और arrival shape लें; duplicate submissions और deadlines जाँचें। Memory, connections, storage और oldest-job age के लिए पर्याप्त लंबा test हो। Node failure, safe scale-in, database reconnect/failover, worker recovery और backup restore शामिल करें। Tool versions, scripts, resource settings, errors और accepted-work reconciliation सुरक्षित रखें। Disruptive tests isolated representative environment या approved window में stop criteria के साथ हों।
सीरीज़ का उपयोगी loop: business outcome मापें, constraint खोजें, सही layer बदलें, outcome और recovery फिर test करें। मूल्यवान artifact evidence register है जिसमें observed, modelled और not yet tested अलग स्पष्ट हों।
समीक्षा: 6 नवंबर 2026। Anichur Rahaman, StoreConsole संस्थापक। पुराने observations सुरक्षित, arithmetic जाँचा गया; extrapolations और planned tests स्पष्ट अलग हैं।
लेखक का परिचय
Anichur Rahaman
पढ़ना जारी रखें
