Databases کو بغیر مردہ connections کے جگانا

Mythex پر published ایپس، اور ان کے databases، کوئی استعمال نہ کرے تو سو جاتے ہیں۔ جب ایپ جاگتی تھی تو وہ اپنا پہلا request 10 سے 12 سیکنڈ تک روک سکتی تھی، کیونکہ وہ ان database connections کو دوبارہ استعمال کرنے کی کوشش کرتی تھی جو سب کچھ سوتے وقت مر چکے تھے۔ اب ہم Spring Boot ایپس کو ایسی database settings دیتے ہیں جو نیند کے بعد بھی محفوظ ہیں، اور agent کو ہدایت دیتے ہیں کہ کسی بھی stack کی ایپ اسی طرح بنائے۔ Hosting platform پر، جاگنے کے بعد پہلا request 12.7 سیکنڈ سے کم ہو کر 2.3 سیکنڈ ہو گیا۔

ایپس اور databases کیوں سوتے ہیں

Mythex کی ایک published ایپ ایک ایسی مشین پر چلتی ہے جو چند منٹ کی بے کاری کے بعد معطل ہو جاتی ہے، اور اس کا database serverless Postgres ہے جو پانچ منٹ کی بے کاری کے بعد سو جاتا ہے اور اگلے request پر جاگتا ہے۔ یہی خاموش ایپ کو سستا رکھتا ہے: آپ اس کے لیے چارج ہوتے ہیں جو database واقعی استعمال کرتا ہے، اور سوتی ہوئی ایپ compute پر کچھ خرچ نہیں کرتی۔ ہم نے billing کے اس پہلو پر databases کی billing ان کے استعمال کے مطابق میں لکھا ہے۔

پکڑ یہ ہے کہ یہ دونوں الگ الگ سوتے ہیں، اور وہ اس پر متفق نہیں کہ connection کیا ہے۔

علامت: پہلی visit سست

زیادہ تر server ایپس ایک connection pool رکھتی ہیں: کھلے database connections کا ایک مختصر سیٹ تیار رکھا جاتا ہے، تاکہ ہر request نیا connection کھولنے کی قیمت نہ دے۔ جو ایپ ہمیشہ چالو رہے اس کے لیے یہ درست ڈیزائن ہے۔

نیند کے ساتھ یہ ہوتا ہے:

1. ایپ چل رہی ہے، اس کے pool میں کچھ بے کار connections ہیں۔
2. کوئی visit نہیں کرتا۔ ایپ کی مشین معطل ہو جاتی ہے، منجمد، اس کا pool جوں کا توں۔
3. Database سو جاتا ہے اور ہر connection کا اپنا سرا گرا دیتا ہے۔
4. ایک visitor آتا ہے۔ ایپ بالکل ویسے ہی جاگتی ہے، مگر ابھی تک وہ connections پکڑے ہوئے ہے جنہیں database اب نہیں جانتا۔
5. Pool ان میں سے ایک connection دیتا ہے۔ اسے پہلے معلوم کرنا پڑتا ہے کہ وہ مر چکا ہے، اسے آزما کر اور انتظار کر کے، اس سے پہلے کہ وہ اسے چھوڑے۔

Spring Boot ایپ میں، ان مردہ connections کی تصدیق پہلے request کو تقریباً 10 سیکنڈ تک روکتی تھی، پھر وہ “Connection is not available” کے ساتھ ناکام ہو جاتا۔ Visitor کو سائٹ بس اٹکی ہوئی لگتی، اور پھر شاید کوئی error دکھتا۔

Spring ایپس کو سب سے زیادہ نقصان کیوں

Spring Boot ایک مقبول Java framework ہے، اور وہ ڈیفالٹ کے طور پر HikariCP نامی connection pool استعمال کرتا ہے۔ Spring اس pool کو settings سے configure کر سکتا ہے، جن میں یہ بھی شامل ہے کہ کتنے بے کار connections رکھنے ہیں۔

مگر Mythex ہر ایپ کو اس کا database ایک واحد DATABASE_URL کی شکل میں دیتا ہے، postgresql://user:pass@host/db کی صورت میں۔ Spring اس شکل کو براہِ راست نہیں پڑھ سکتا۔ تو Mythex پر بنی Spring ایپس اس URL کو parse کر کے کوڈ میں اپنا pool خود بنا رہی تھیں، اور ہاتھ سے بنایا گیا pool Spring کی تمام spring.datasource.* settings کو نظرانداز کرتا ہے۔ اگر کوئی درست pool settings جانتا بھی، تب بھی ان کے لاگو ہونے کی کوئی جگہ نہ ہوتی۔

حل، حصہ 1: وہ settings جو Spring استعمال کر سکے

جب کسی project میں database ہو تو اب ہم اسے وہ environment variables بھی دیتے ہیں جو Spring براہِ راست پڑھتا ہے:

• SPRING_DATASOURCE_URL، SPRING_DATASOURCE_USERNAME اور SPRING_DATASOURCE_PASSWORD، جو DATABASE_URL سے بدلے جاتے ہیں (SSL لازمی، جب تک URL خود کچھ اور نہ کہے)۔
• Pool settings جو نیند کے بعد بھی کام کریں:

کوئی بے کار connection روکے بغیر، جاگی ہوئی ایپ ایک تازہ connection کھولتی ہے، بجائے اس کے کہ مردہ connections میں سے گزرے۔

ان variables کی موجودگی میں Spring خود pool configure کرتا ہے، اور settings لاگو ہو جاتی ہیں۔ Project نے خود جو کچھ طے کیا ہو وہ ہمیشہ جیتتا ہے؛ ہم صرف وہی بھرتے ہیں جو غائب ہو۔ Spring کے علاوہ ایپس ان variables کو نظرانداز کرتی ہیں۔

وہ تفصیل جو تقریباً کچھ نہ کرتی

Spring environment variables کو اپنی settings سے ایک ایسے قاعدے سے جوڑتا ہے جس میں غلطی آسان ہے۔ Setting minimum-idle کو SPRING_DATASOURCE_HIKARI_MINIMUMIDLE لکھنا ہوتا ہے، جس میں dashes نہ ہوں اور الفاظ آپس میں جڑے ہوں۔ اسے SPRING_DATASOURCE_HIKARI_MINIMUM_IDLE لکھنا، جو زیادہ قدرتی لگتا ہے، ایک مختلف، غیر موجود setting (minimum.idle) سے جڑتا ہے اور خاموشی سے نظرانداز ہو جاتا ہے۔

یہ اس قسم کی غلطی ہے جو ہر review سے گزر جاتی ہے اور production میں کچھ نہیں کرتی۔ اس لیے ایک ٹیسٹ دیکھتا ہے کہ قدریں مقرر ہیں اور کوئی variable underscore سے جڑی شکل میں نہیں۔

حل، حصہ 2: باقی ہر stack

Spring واحد framework نہیں جس کے پاس pool ہے، اور ہم ہر زبان کی ہر library کو پہلے سے configure نہیں کر سکتے۔ اس لیے Mythex کا agent، یعنی وہ AI جو آپ کی ایپ لکھتا ہے، اب کسی بھی stack کے لیے ایک مستقل ہدایت رکھتا ہے: published ایپس اور ان کے databases بے کار ہونے پر سو جاتے ہیں، اس لیے جو connection کھلا رکھا گیا وہ اگلے request پر مردہ ہو سکتا ہے۔ اسے یہ کرنا چاہیے:

• کوئی بے کار database connection کھلا نہ رکھے، یا استعمال سے پہلے ہر ایک کی جانچ کرے،
• connection کی خرابی پر ایک بار دوبارہ کوشش کرے، اور
• ماحول میں platform کی دی ہوئی database settings استعمال کرے، نہ کہ DATABASE_URL کو parse کر کے اپنا pool بنائے۔

آخری نکتہ حصہ 1 کے ساتھ دائرہ مکمل کرتا ہے: وہ ایپ جو فراہم کردہ settings پر بنی ہو وہ خودکار طور پر نیند سے محفوظ configuration اٹھا لیتی ہے۔

نتیجہ

اس platform پر ناپا گیا جس پر ہم published ایپس چلاتے ہیں، جاگنے کے بعد پہلا request 12.7 سیکنڈ سے 2.3 سیکنڈ ہو گیا۔

ہم نے اس سے کیا سیکھا

• ہر سونے والی تہہ کو اس پر متفق ہونا چاہیے کہ کیا باقی رہتا ہے۔ منجمد ایپ اور سوتے ہوئے database نے ہر ایک نے معقول فیصلہ کیا۔ مل کر، ایپ ایسی حالت کے ساتھ جاگی جو اب سچ نہیں تھی۔
• Always-on سرورز کے لیے بنائے گئے ڈیفالٹس ان ایپس کے لیے موزوں نہیں جو صفر تک سکڑتی ہیں۔ Connections کو گرم رکھنا اچھا خیال ہے جب تک ان کے گرد سب کچھ ٹھنڈا نہ ہو جائے۔
• Frameworks کو ان کا ڈیٹا ان کی اپنی شکل میں دیں۔ ہمارے لیے ایک URL سادہ تھا، مگر اس نے ہر Spring ایپ کو ایک ایسا pool ہاتھ سے بنانے پر مجبور کیا جو اپنی ہی configuration کو نظرانداز کرتا تھا۔
• ٹیسٹ کریں کہ setting کا ہجہ وہی ہے جو framework پڑھتا ہے۔ غلط نام کے نیچے درست قدر خاموشی سے کچھ نہیں کرتی۔

اگر آپ Mythex پر databases کے کام کرنے کے طریقے سے نئے ہیں تو database docs اور Postgres کیا ہے پر ہماری وضاحت دیکھیں۔