کیس اسٹڈی
آپ کی مرکزی فہرست کا صفحہ اچانک کیوں کھلنا بند ہو جاتا ہے
ایک کلائنٹ کی مرکزی فہرست کھلنا بند ہو گئی جبکہ باقی سب صفحات کام کر رہے تھے۔ وجہ ایک ایسا ریکارڈ تھا جو باقی سب سے کہیں بڑا تھا، اور یہی خرابی ایک پس منظر کے کام میں خاموشی سے ناکام ہو رہی تھی۔
اہم نکات
- جو فہرست اچانک کھلنا بند کر دے، اس کے پیچھے اکثر ایک حد سے بڑا ریکارڈ ہوتا ہے، کسی کی کی ہوئی تبدیلی نہیں۔
- ڈیٹابیس قطاریں پوری ترتیب دیتا ہے، اس لیے ترتیب کے لیے مختص میموری سے بڑا ایک ریکارڈ پورا صفحہ ناکام کر دیتا ہے۔
- فہرست کو صرف وہی لوڈ کرنا چاہیے جو وہ دکھاتی ہے؛ لمبی دستاویزات اور فائلیں اس صفحے کی ہیں جو ایک شے کھولتا ہے۔
- یہی وجہ اکثر کسی شیڈول شدہ پس منظر کے کام میں خاموشی سے ناکام ہو رہی ہوتی ہے جس کی کسی کو اطلاع نہیں دی جاتی۔
- میموری کی حد بڑھانا مسئلہ ہٹانے کے بجائے اگلے، اس سے بڑے ریکارڈ کی طرف سرکا دیتا ہے۔
ایک کلائنٹ کی ٹیم نے اپنے اندرونی نظام میں مرکزی فہرست کھولی تو صفحے پر غلطی نظر آئی۔ اس اسکرین کو کسی نے بدلا نہیں تھا، اور باقی ہر صفحہ کام کر رہا تھا۔ وجہ ایک ہی ریکارڈ تھا جو باقی سب سے کہیں زیادہ بڑھ گیا تھا۔
جو فہرست نہ کھلے وہ ٹیم کو کیا مہنگا پڑتا ہے
مرکزی فہرست وہ جگہ ہے جہاں ٹیم اپنا کام ڈھونڈتی، کھولتی اور مکمل کرتی ہے، اس لیے جب وہ کھلنا بند ہو جائے تو پوری ٹیم رک جاتی ہے۔ اس کلائنٹ کے لیے یہ فہرست وہ اشیاء رکھتی ہے جن پر ٹیم کام کرتی ہے، نئی سب سے اوپر۔ جو صفحہ وہ بغیر سوچے استعمال کرتے تھے اب صرف ایک غلطی دکھا رہا تھا، جبکہ باقی ہر اسکرین معمول کے مطابق چل رہی تھی۔
یہی امتزاج، ایک خراب اسکرین اور کہیں کوئی تبدیلی نہیں، ایسی خرابیوں کو پراسرار بنا دیتا ہے۔ ہمارے تجربے میں یہ لوٹ کر آتی ہیں، کیونکہ خرابی کسی شخص کے کیے سے نہیں بلکہ ڈیٹا کے بڑھنے سے بڑھتی ہے۔ یہی علامت ہر بڑھتے نظام میں سامنے آتی ہے: اندرونی ٹول کی فہرست خراب، CRM کی فہرست نہ کھلنا، وہ اسکرین جس پر ٹیم سارا دن انحصار کرتی ہے۔
ایڈمن فہرست کا صفحہ نہ کھلنے کی وجہ اکثر ایک بڑا ریکارڈ ہوتی ہے
نئی اشیاء پہلے دکھانے کے لیے ڈیٹابیس قطاریں ترتیب دیتا ہے، اور وہ انہیں پورا پورا ترتیب دیتا ہے۔ ڈیٹابیس وہ ذخیرہ ہے جہاں اندرونی نظام اپنے ریکارڈ رکھتا ہے، اور ترتیب تب لگتی ہے جب آپ ریکارڈ کسی خاص ترتیب میں مانگیں۔ اس قسم کی ترتیب کے لیے ڈیٹابیس کام کی جگہ کے طور پر ایک مقررہ مقدار میں میموری مختص کرتا ہے، اور شروع کرنے سے پہلے ہر قطار کو نہیں تولتا: ہر قطار اپنے سارے مواد کے ساتھ پوری ترتیب میں جاتی ہے۔ اس اجازت سے بڑی ایک قطار پوری فہرست کو ناکام کر دیتی ہے، چاہے باقی کتنی ہی چھوٹی ہوں۔
اسی لیے ریکارڈ کے حجم کا بڑھنا اتنا ہی یقینی طور پر چیزوں کو توڑتا ہے جتنا ان کی تعداد کا بڑھنا۔ ریکارڈ بڑھانے سے فہرست سست ہوتی ہے؛ ایک غیر معمولی طور پر بڑا ریکارڈ بڑھانے سے وہ کھلنا ہی بند ہو سکتی ہے۔
ہمارے انجینئر نے کیا پایا
غلطی ڈیٹابیس سے آئی اور کہہ رہی تھی کہ ترتیب دینے کے لیے میموری ختم ہو گئی ہے۔ چونکہ نئی اشیاء پہلے دکھائی جا رہی تھیں، قطاریں ترتیب دی جا رہی تھیں، اور ہر قطار عنوان اور تاریخ کے ساتھ ایک بھاری فیلڈ بھی اٹھائے ہوئے تھی۔ وہ فیلڈ متن کا ایک لمبا ٹکڑا تھا جو فہرست کبھی دکھاتی ہی نہیں تھی۔
یہ فیلڈز عام طور پر چھوٹے ہوتے ہیں۔ ٹیم نے حال ہی میں ایک نئی قسم کی شے بنانا شروع کی تھی، اور ان میں سے ایک میں پہلے سے کہیں زیادہ لمبی فیلڈ تھی۔ ڈیٹابیس اس قسم کی ترتیب کے لیے ایک مقررہ مقدار میں کام کی میموری مختص کرتا ہے، اور وہ ایک قطار اب اس میں نہیں سمائی، اس لیے پوری فہرست ناکام ہو گئی۔ ڈیٹابیس کی میموری بڑھانا صرف حد کو اگلے، اس سے بڑے ریکارڈ تک سرکا دیتا۔
موڑ ایک سادہ سوال تھا: کیا فہرست کو اس فیلڈ کی ضرورت ہے ہی؟ وہ عنوان، حالت اور تاریخ دکھاتی ہے، بس۔
وہی غلطی کہیں اور تلاش کرنے سے باقی کہانی بھی سامنے آئی۔ یہی خرابی ایک پس منظر کے کام میں خاموشی سے ناکام ہو رہی تھی، ایسا کام جو ٹائمر پر چلتا ہے اور کوئی اسے دیکھتا نہیں۔ کسی نے اسے دیکھا ہی نہیں تھا۔ ٹیم کو صرف سامنے والی اسکرین کا پتہ تھا۔
ہم نے کیا بدلا
ہم نے فہرست کو ہر شے بھاری فیلڈ کے بغیر پڑھنے پر لگایا، تاکہ صفحہ صرف عنوان، حالت اور تاریخ لوڈ کرے۔ فیلڈ تب پڑھی جاتی ہے جب کوئی وہ شے کھولتا ہے، اور صرف تبھی۔ ہم نے ایک انڈیکس بھی شامل کیا، یعنی ایسا ڈھانچہ جو اشیاء کو ان کی آخری تبدیلی کی ترتیب میں رکھتا ہے، تاکہ تازہ ترین پہلے دکھانے کے لیے ترتیب دینے کی ضرورت ہی نہ رہے۔
تھوڑی دیر بعد اسی سوچ نے پورے نظام کو ڈھانپ لیا: جب تک مخصوص فیلڈز نہ مانگی جائیں، ان اشیاء کی درخواست اب بھاری فیلڈ کو بطور طے شدہ چھوڑ دیتی ہے، پس منظر کے کام کی درخواستیں بھی شامل۔ ایک شے کھولنے پر فیلڈ پوری پڑھی جاتی ہے۔ اب ایک نئی خودکار جانچ پکڑ لیتی ہے اگر فہرست یا کام دوبارہ وہ فیلڈ مانگنے لگیں۔
اب کاروبار کے پاس کیا ہے
تبدیلیاں اسی دن کلائنٹ کے نظام پر لاگو ہو گئیں۔ فہرست پھر کھلتی ہے اور پس منظر کا کام پھر چلتا ہے۔ کسی بھی لمبائی کی شے اب ان دونوں میں سے کسی کو نہیں توڑ سکتی، اور ایک شے کھولنا پہلے کی طرح کام کرتا ہے۔
آپ خود کیا جانچ سکتے ہیں
- اپنے ڈویلپر سے پوچھیں کہ آپ کی سب سے مصروف فہرست کا صفحہ ہر قطار کے لیے کیا لوڈ کرتا ہے، اور کیا وہ کچھ ایسا لوڈ کرتا ہے جو اسکرین کبھی دکھاتی ہی نہیں۔
- پوچھیں کہ پس منظر کا کوئی کام ناکام ہو تو کسی کو بتایا جاتا ہے یا نہیں، اور آج آپ کو کیسے پتہ چلے گا اگر کوئی خاموشی سے ناکام ہو رہا ہو۔
- اگر کوئی کہے کہ غلطی دور کرنے کے لیے میموری کی حد بڑھا دیں، تو پہلے پوچھیں کہ اسکرین کو اصل میں کیا چاہیے؛ زیادہ حد صرف اگلے، اس سے بڑے ریکارڈ کا انتظار کرتی ہے۔
- جب آپ اپنے نظام میں نئی قسم کا کام شروع کریں، جیسے کہیں لمبی دستاویزات یا فائلیں، تو پوچھیں کہ کیا کوئی اسکرین ایک شے کے حجم سے اٹک سکتی ہے۔
- صرف اس اسکرین پر نہ رکیں جس کی کسی نے شکایت کی۔ پوچھیں کہ کیا یہی خرابی ان کاموں میں بھی بیٹھی ہے جنہیں کوئی نہیں دیکھتا۔
آگے کیا کریں
وہ فہرست لیں جو آپ کی ٹیم سب سے زیادہ استعمال کرتی ہے اور وہی سوال پوچھیں جس نے یہ معاملہ کھولا: اس اسکرین کو ہر قطار کے لیے کیا چاہیے، اور وہ بہرحال کیا لوڈ کر رہی ہے۔ پھر ایسا طریقہ مانگیں جس سے پتہ چلے کہ پس منظر کا کوئی کام ناکام ہوا ہے، بجائے اس کے کہ خراب اسکرین سے پتہ چلے۔ ایسی خرابی کی جڑ تک پہنچنا وہ کام ہے جو ہمارے انجینئر کلائنٹس کے لیے کرتے ہیں، اور یہ عموماً ایک سادہ سوال سے شروع ہوتا ہے کہ صفحہ اصل میں کیا مانگ رہا ہے۔
لوگ جو پوچھتے ہیں
مجھے کیسے پتہ چلے کہ پس منظر کا کوئی کام خاموشی سے ناکام ہو رہا ہے؟
اپنے نظام کی دیکھ بھال کرنے والے سے پوچھیں کہ شیڈول شدہ کاموں کی ناکامی کہیں درج ہوتی ہے یا نہیں اور کسی کو اطلاع دی جاتی ہے یا نہیں۔ اگر جواب یہ ہو کہ کسی کو پتہ نہیں چلے گا، تو پہلے یہی ٹھیک کرنا چاہیے، کیونکہ ناکام ہوتا کام کوئی نظر آنے والی علامت پیدا نہیں کرتا جب تک کوئی اس کے نتیجے پر انحصار نہ کرے۔
جب کسی نے کچھ بدلا ہی نہیں تو ہماری فہرست کا صفحہ کیوں خراب ہو گیا؟
کیونکہ ڈیٹا بدلا، اسکرین نہیں۔ جو فہرست اپنی قطاریں ترتیب دیتی ہے وہ ڈیٹابیس سے ہر قطار کام کی میموری میں رکھواتی ہے، اور ایک ریکارڈ جو اجازت شدہ جگہ سے بڑھ جائے، صفحہ روکنے کے لیے کافی ہے۔ ایسا ہونے سے پہلے اسکرین خود کافی عرصہ بغیر تبدیلی کے رہ سکتی ہے۔
ایک ریکارڈ پورے صفحے کو کھلنے سے کیسے روک سکتا ہے؟
ڈیٹابیس ساری قطاریں اکٹھی ترتیب دیتا ہے، اور ترتیب دیتے وقت ریکارڈ کے بڑے حصوں کو نہیں چھوڑتا۔ اگر ایک قطار اس ترتیب کے لیے مختص میموری سے بڑی ہو، تو پورا عمل ناکام ہو جاتا ہے، اور صفحے کے پاس دکھانے کو کچھ نہیں بچتا۔ باقی ریکارڈ چھوٹے ہونا کوئی مدد نہیں کرتا۔
کیا ہمیں بس ڈیٹابیس کی میموری کی حد بڑھا دینی چاہیے؟
حد بڑھانے سے غلطی ابھی کے لیے غائب ہو سکتی ہے، لیکن یہ جواب نہیں دیتا کہ صفحہ اتنا کچھ لوڈ کیوں کر رہا تھا۔ اگلا لمبا ریکارڈ نئی حد سے آگے جا سکتا ہے، اور وہی ناکامی لوٹ آتی ہے۔ بہتر ہے کہ پوچھیں کہ اسکرین کو اصل میں کیا چاہیے اور صرف وہی لوڈ ہو۔
فہرست کے صفحے کو ہر قطار کے لیے کیا لوڈ کرنا چاہیے؟
فہرست کو صرف وہی فیلڈز لوڈ کرنی چاہئیں جو وہ دکھاتی ہے، جیسے عنوان، حالت اور تاریخ۔ لمبا متن، فائلیں یا پیداوار کی تفصیلات اس صفحے کی ہیں جو ایک شے کھولتا ہے۔ اس سے فہرست تیز رہتی ہے اور ایک بڑا ریکارڈ اسے توڑ نہیں سکتا۔