آپ ایک ویب سروس کے لیے آن کال ہیں: انسٹینسز کے فلیٹ کے سامنے لوڈ بیلنسر، ڈیٹا بیس کے سامنے کیش، اور 99.9 % دستیابی کا ہدف۔ ہر منٹ ماڈل قطار کی تاخیر، ٹائم آؤٹ، کیش ہٹس اور ڈیٹا بیس لوڈ نصابی فارمولوں سے نکالتا ہے — اور آپ کے فیصلوں کی قیمت بھی۔
فلیٹ کی نچلی حد۔ بڑھانے سے انسٹینس فوراً شروع ہوتے ہیں — پھر بھی سروس دینے سے پہلے بوٹ کی تاخیر چاہیے۔
استعمال پر ہدف کی پیروی؛ جب تک انسٹینس شروع ہو رہے ہوں نیا اسکیل آؤٹ نہیں۔ بند = ٹھیک کم از کم۔
کم = زیادہ گنجائش اور زیادہ خرچ۔ ناپا گیا استعمال 100 % سے زیادہ نہیں ہو سکتا، اس لیے سیر شدہ فلیٹ صرف قدم بہ قدم بڑھتا ہے۔
لمبا TTL = زیادہ ہٹس، مگر جواب پرانے ہو سکتے ہیں (اوسط عمر ≈ TTL/2)۔
6 منٹ تک گرم کیز لوڈ کرتا ہے (فی منٹ کیش کا +12 %) اضافی 600 ڈیٹا بیس کوئری/s کی قیمت پر۔
کم ترجیح والے 30 % (پری فیچ، بیچ، کرالر) کا حصہ جو لوڈ بیلنسر پر "بعد میں کوشش کریں" کے ساتھ مسترد ہوتا ہے۔
بھاری فیچر ہر درخواست پر 20 ms CPU اور ایک ڈیٹا بیس کوئری بڑھاتا ہے۔ بند = نرم تنزلی۔
آخری درست بلڈ کو نئے فلیٹ پر دوبارہ ڈیپلائے کرتا ہے (5 منٹ، دو بار بل ہوتا ہے)، پھر ٹریفک سوئچ کرتا ہے۔ دوبارہ دبانے سے تیاری نئے سرے سے شروع ہوتی ہے؛ اگر کوئی خراب بلڈ لائیو نہ ہو تو صرف پیسے خرچ ہوتے ہیں۔
| برن ریٹ (1 h) | 0.0 × |
|---|---|
| درخواستیں | 1125 req/s |
| سروس دیتے انسٹینس | 10 |
| شروع ہوتے انسٹینس | 0 |
| کیش ہٹ ریٹ | 77 % |
| ڈیٹا بیس کا استعمال | 19 % |
| روکا گیا ٹریفک | 0 % |
| فلیٹ کی لاگت | 4.00 $/h |
| اب تک کی لاگت | 0.00 $ |
| کیش جوابات کی اوسط عمر | 30 s |
| خراب بلڈ پر ٹریفک | 0 % |
| سفارشات دستیاب | 100 % |
09:10 بجے نئی بلڈ جاری ہوتی ہے۔ مہینہ پہلے ہی سخت رہا ہے: ایرر بجٹ کا صرف 20 % باقی ہے۔ ڈیپلائے کے چند منٹ بعد برن ریٹ پیج بجتا ہے۔ بجٹ کی حفاظت کریں۔
سروس کا ایک لنک تیزی سے پھیل رہا ہے اور آج صبح کسی وقت ٹریفک میں اچانک اضافے کی توقع ہے — کوئی نہیں جانتا کب، یا کتنا بڑا۔ آج نئے انسٹینسز کو بوٹ ہونے میں 8 منٹ لگتے ہیں۔ جب وہ آئے تو خالی گنجائش پر پیسہ جلائے بغیر غلطیاں اور تاخیر کم رکھیں۔
دوپہر کی چوٹی پر ایک دیکھ بھال اسکرپٹ پورا کیش خالی کر دیتا ہے۔ اب ہر درخواست ڈیٹا بیس پر جاتی ہے، جو معمول کے 85 % ہٹ ریٹ کے لیے بنایا گیا تھا۔ ڈیٹا بیس پر بوجھ ڈالے بغیر سروس بحال کریں۔
ہر تعلق جو سمیولیٹر استعمال کرتا ہے، اس کے ماخذ کے ساتھ۔ مفروضے کے طور پر نشان زد مستقل توضیحی کیلیبریشنز ہیں۔
λ(t) = base × (1 + 0.25·sin(2π(t + clock − 6 h)/24 h)) × surge(t), clock = time of day at the start (peak at 12:00); count/min ≈ N(60λ, √(60λ)) × (1 + N(0, 0.02))[6]مفروضہ: ورکرز کی تعداد، سروس کے اوقات، ڈیٹا بیس کی گنجائش، کیش کا سائز، دوبارہ بھرنے کی رفتار، قیمتیں اور خراب بلڈ کی خرابی کی شرح ایک درمیانی ویب سروس کی مثالی قدریں ہیں۔N = instances × 16 workers, a = λ·S; C(a, N) = B / (1 − (a/N)(1 − B)), B = Erlang B[3][6]P(W > t) = C·e^(−(N/S − λ)·t); timeouts = P(W > 2 s); a ≥ N ⇒ failed share = 1 − N/a[3]p99 ≈ S·ln 100 + ln(C/0.01)/(N/S − λ) (service + waiting quantile, an approximation)[3][6]تخمینہ: سروس اور انتظار کے کوانٹائل جمع کرنا ان کے مجموعے کا عین p99 نہیں (یہ تھوڑا زیادہ یا کم ہو سکتا ہے)؛ ہر منٹ کے اندر قطار کو مستحکم مانا گیا ہے کیونکہ درخواستیں ملی سیکنڈ میں ہوتی ہیں۔busy workers L = λ·S ⇒ utilization = λ·S / N[4]hit = warm × rT/(1 + rT), r = λ / 20,000 objects; mean age of a cached answer ≈ T/2[5]DB load = λ·q·(1 − hit); query time = 5 ms/(1 − ρ_db) (≤ 250 ms); S = S_app + (1 − hit)·q·query time[6]مفروضہ: ورکرز کی تعداد، سروس کے اوقات، ڈیٹا بیس کی گنجائش، کیش کا سائز، دوبارہ بھرنے کی رفتار، قیمتیں اور خراب بلڈ کی خرابی کی شرح ایک درمیانی ویب سروس کی مثالی قدریں ہیں۔budget = 1 − SLO = 0.1 %; burn = error rate / 0.1 %; Δbudget per min = burn / 43,200; burn (1 h) = mean error rate over the last 60 min / 0.1 % (window pre-filled with the opening minute)[1][2]desired = ⌈serving × utilization / target⌉ (utilization saturates at 100 %); new instances serve after the boot delay[6]مفروضہ: ورکرز کی تعداد، سروس کے اوقات، ڈیٹا بیس کی گنجائش، کیش کا سائز، دوبارہ بھرنے کی رفتار، قیمتیں اور خراب بلڈ کی خرابی کی شرح ایک درمیانی ویب سروس کی مثالی قدریں ہیں۔16 workers/instance · app time 50 ms (+20 ms and +1 query with the feature on) · 2 queries/request · DB 4,000 queries/s · 20,000 hot objects · cache refill τ = 30 min (slower while the DB is saturated) · warm-up job +12 %/min for 6 min, +600 queries/s · timeout 2 s · 30 % low-priority traffic · bad build +5 % errors, ×1.25 CPU · rollback 5 min · $0.40 per instance-hour · scale-in by ≤ 20 % of the fleet after 10 quiet minutes · up to 40 instancesمفروضہ: ورکرز کی تعداد، سروس کے اوقات، ڈیٹا بیس کی گنجائش، کیش کا سائز، دوبارہ بھرنے کی رفتار، قیمتیں اور خراب بلڈ کی خرابی کی شرح ایک درمیانی ویب سروس کی مثالی قدریں ہیں۔بے ترتیبی: سیڈ والا mulberry32 جنریٹر؛ استعمال شدہ تقسیمیں — یکساں، ایکسپونینشل (الٹا CDF)، نارمل (Box–Muller)، پوائسن (Knuth)۔ سیڈ دکھایا جاتا ہے اور شیئر کیا جا سکتا ہے۔
تعلیمی ماڈل — عملی فیصلوں کے لیے نہیں۔ حقیقی سائٹس ہر مستقل کو اپنے آلات اور ڈیٹا کے مطابق ترتیب دیتی ہیں۔