ڈویلپرز دیکھتے ہیں کہ ان کی حال ہی میں لانچ ہونے والی ایپ اس وقت تعطل کا شکار ہو جاتی ہے جب چند ہزار صارفین "go" پر کلک کرتے ہیں، اور یہ سست روی شاذ و نادر ہی کوڈ میں کسی بگ کی وجہ سے ہوتی ہے – بلکہ یہ سرور کے CPU اور RAM کی جگہ کے لیے جنگ ہوتی ہے۔ یہ رکاوٹ طویل پیج لوڈنگ، ٹائم آؤٹ، یا مکمل کریش کے طور پر ظاہر ہوتی ہے، اور یہ صارف کے تجربے، آمدنی اور برانڈ پر اعتماد کو نقصان پہنچاتی ہے۔

کیوں ایک سرور جو لیب میں ٹھیک چل رہا تھا وہ پروڈکشن میں ٹھپ ہو سکتا ہے

ڈویلپمنٹ کے دوران ایک واحد ڈویلپر چند درخواستیں بھیجتا ہے، اس لیے سرور کے وسائل زیادہ تر وقت خالی رہتے ہیں۔ جب ایپ لائیو ہوتی ہے، تو ہر وزیٹر ایک ایسی درخواست پیدا کرتا ہے جس کے لیے دو بنیادی اجزاء درکار ہوتے ہیں:

  • CPU (central processing unit) – وہ پروسیسر جو ہر لوپ، فنکشن اور حساب کتاب کو چلاتا ہے۔ اسے ایک ایسے شیف کے طور پر سمجھیں جو ایک وقت میں صرف محدود تعداد میں پکوان تیار کر سکتا ہے۔ ایک آرڈر فوری طور پر سرو کیا جاتا ہے؛ سو آرڈرز کا مطلب ہے کہ شیف اب بھی اسی رفتار سے کام کر رہا ہے، لیکن کھانے والے زیادہ دیر انتظار کرتے ہیں۔
  • RAM (random-access memory) – اس ڈیٹا کے لیے عارضی اسٹوریج جس کی ضرورت CPU کو درخواست سنبھالتے وقت ہوتی ہے۔ یہ ایک ایسی میز کی طرح ہے جہاں شیف ہر ڈش کے اجزاء رکھتا ہے۔ اگر میز بھر جائے، تو شیف کو نئے آرڈر لینا تب تک بند کرنا پڑتا ہے جب تک جگہ خالی نہ ہو جائے۔

جب ہزاروں صارفین بیک وقت لاگ ان ہوتے ہیں، تو ہر درخواست CPU کے وقت کا اپنا حصہ اور RAM کا اپنا حصہ لیتی ہے۔ سرور کے دونوں وسائل کا محدود ذخیرہ درخواستوں کے درمیان تقسیم ہو جاتا ہے، اور قطار بڑھتی جاتی ہے۔ سرور خود سست نہیں ہوا؛ بلکہ ہر درخواست کے لیے انتظار کا وقت بڑھ گیا ہے۔

"بس ایک بڑا باکس خرید لیں" کا لالچ

ایک عام پہلا ردعمل مشین کو اپ گریڈ کرنا ہے – ایک ایسا عمل جسے vertical scaling کہا جاتا ہے۔ مزید CPU کور یا زیادہ RAM شامل کرنے سے گنجائش میں بہتری آتی ہے: 4 کور سے 16، یا 8 GB سے 64 GB پر منتقل ہونا، کسی بھی کوڈ کو تبدیل کیے بغیر ٹریفک کے بڑے دباؤ کو برداشت کر سکتا ہے۔

تاہم، vertical scaling ایک سخت حد سے ٹکرا جاتی ہے:

  • Physical limits – ہر مدر بورڈ صرف ایک مخصوص تعداد میں کور اور ایک محدود مقدار میں میموری کو ہوسٹ کر سکتا ہے۔
  • Diminishing returns – ہر اضافی کور یا گیگا بائٹ پچھلے والے سے زیادہ قیمت رکھتا ہے، جبکہ کارکردگی میں اضافہ کم ہوتا جاتا ہے۔
  • Single point of failure – اگر ضرورت سے زیادہ بڑا سرور ڈاؤن ہو جائے، تو پوری سروس غائب ہو جاتی ہے۔

ان محدودات کی وجہ سے، صنعت کے بڑے کھلاڑیوں نے – اسٹریمنگ پلیٹ فارمز، سرچ انجن، ای کامرس سائٹس – ایک ہی بڑی مشین (monster machine) سے کنارہ کشی اختیار کر لی ہے۔

متبادل: بوجھ کو بہت سے چھوٹے باکسز میں تقسیم کرنا

ایک اونچا ٹاور بنانے کے بجائے، آپریٹرز مناسب سائز کے مزید سرورز شامل کرتے ہیں اور انہیں ٹریفک بانٹنے دیتے ہیں۔ یہ horizontal scaling کا طریقہ ہر مشین کو کارکردگی کے آرام دہ دائرے میں رکھتا ہے اور ورٹیکل اپ گریڈ کے اخراجات میں تیزی سے اضافے سے بچاتا ہے۔

بہت سی مشینوں کو ہم آہنگ کرنے کے لیے ایک load balancer کی ضرورت ہوتی ہے – یہ ایک سافٹ ویئر یا ہارڈ ویئر ہے جو ہر آنے والی درخواست وصول کرتا ہے اور اسے اس سرور کو بھیج دیتا ہے جس کے پاس سب سے زیادہ دستیاب گنجائش ہو۔ بیلنسر کلائنٹ سے پیچیدگی کو چھپا دیتا ہے؛ صارف کے نقطہ نظر سے سائٹ اب بھی ایک ہی اینڈ پوائنٹ کی طرح نظر آتی ہے۔

Horizontal scaling لچک بھی لاتی ہے۔ اگر ایک نوڈ کریش ہو جائے، تو بیلنسر صرف ٹریفک کو باقی صحت مند نوڈز کی طرف موڑ دیتا ہے، جس سے سروس زندہ رہتی ہے۔

جب آپ مشینیں شامل کرنا شروع کریں تو کن باتوں کا خیال رکھیں

  • Stateless design – درخواستیں صرف کسی مخصوص سرور کی میموری میں محفوظ ڈیٹا پر انحصار نہیں کرنی چاہئیں؛ ورنہ صارف کو ایسے نوڈ پر بھیجا جا سکتا ہے جس کے پاس مطلوبہ سیاق و سباق (context) نہ ہو۔ مشترکہ کیشز (shared caches) یا ڈیٹا بیسز کا استعمال اس کا حل ہے۔
  • Health checks – بیلنسر کو کسی ناکام ہوتے ہوئے سرور کا فوری پتہ لگانے اور اسے ٹریفک بھیجنا بند کرنے کے قابل ہونا چاہیے۔
  • Auto-scaling policies – بہت سے کلاؤڈ پلیٹ فارمز آپ کو ایسی حدیں (CPU کا استعمال، درخواست کی تاخیر) متعین کرنے کی اجازت دیتے ہیں جو خود بخود instances کو شروع یا بند کر دیتے ہیں، جس سے اخراجات طلب کے مطابق رہتے ہیں۔

جوابی نکتہ: vertical scaling ختم نہیں ہوئی

چھوٹی ٹیموں یا کم ٹریفک والی ایپس کے لیے، ایک طاقتور سرور سادہ ترین اور سستا ترین حل ہو سکتا ہے۔ اگر ٹریفک میں اضافہ قابلِ پیش گوئی ہو (مثلاً کسی شیڈول شدہ پروڈکٹ لانچ کے وقت) تو نئے instances کا پورا بیڑا تیار کرنے کے بجائے عارضی ورٹیکل اپ گریڈ زیادہ عملی ہو سکتا ہے۔

اصل بات یہ پہچاننا ہے کہ کب "بڑا باکس" والا طریقہ متناسب قدر فراہم کرنا بند کر دیتا ہے اور پھر تقسیم (distribution) کے لیے منصوبہ بندی شروع کر دیں۔

خلاصہ

لانچ کے بعد سرور کی رفتار میں کمی عام طور پر وسائل کے استعمال میں مقابلے (resource-contention) کا مسئلہ ہوتی ہے، نہ کہ کوڈ کی کوئی خرابی۔ CPU سائیکلز اور RAM سلاٹس محدود ہوتے ہیں، اور جب بہت سی درخواستیں ایک ساتھ آتی ہیں تو وہ قطار میں لگ جاتی ہیں، جس سے رسپانس ٹائم (response times) بڑھ جاتا ہے۔ ورٹیکل اسکیلنگ (Vertical scaling) آپ کو تھوڑی سی اضافی گنجائش فراہم کرتی ہے لیکن جلد ہی یہ جسمانی اور معاشی حدود کا شکار ہو جاتی ہے۔ ہورائزنٹل اسکیلنگ (Horizontal scaling)—یعنی لوڈ بیلنسر (load balancer) کے پیچھے مزید کم طاقتور سرورز کا اضافہ کرنا—ٹریفک بڑھنے کے ساتھ ساتھ ایک سستا اور زیادہ مستحکم راستہ فراہم کرتی ہے۔ جس لمحے آپ کو قطار کے طویل ہونے کا احساس ہو، یہ جائزہ لینے کا وقت ہے کہ آیا چند مزید کورز (cores) کافی ہوں گے یا آپ کو لوڈ کو کئی مشینوں پر تقسیم کرنا شروع کر دینا چاہیے۔

ماخذ: dev.to آرٹیکل “Why Servers Slow Down – CPU, RAM and the hidden cost of every request.”