Database ကို နိုးစေစဉ် သေနေသော Connection မရှိစေရန်

Mythex ပေါ်ရှိ publish လုပ်ထားသော အက်ပ်များနှင့် ၎င်းတို့၏ database များသည် မည်သူမျှ မသုံးသောအခါ အိပ်ပျော်သည်။ အက်ပ်နိုးလာသောအခါ ပထမ request ကို ၁၀–၁၂ စက္ကန့် ကိုင်ထားနိုင်သည်။ အိပ်နေစဉ် သေသွားသော database connection များကို ပြန်သုံးရန် ကြိုးစားသောကြောင့် ဖြစ်သည်။ ယခု Spring Boot အက်ပ်များကို sleep ကို ဖြတ်ကျော်နိုင်သော database ဆက်တင်များ ပေးပြီး agent ကို မည်သည့် stack ဖြစ်စေ အလားတူ တည်ဆောက်ရန် ပြောထားသည်။ Hosting ပလက်ဖောင်းပေါ်တွင် နိုးပြီးနောက် ပထမ request သည် ၁၂.၇ စက္ကန့်မှ ၂.၃ စက္ကန့်သို့ ပြောင်းခဲ့သည်။

အက်ပ်နှင့် database အိပ်ရခြင်း အကြောင်းရင်း

Mythex ပေါ်ရှိ publish လုပ်ထားသော အက်ပ်သည် အချိန်မကြာ idle ဖြစ်ပါက ရပ်သွားသော စက်ပေါ်တွင် run သည်။ Database သည် serverless Postgres ဖြစ်ပြီး idle ၅ မိနစ်အကြာ အိပ်ပျော်ကာ နောက် query တွင် နိုးသည်။ ထိုသို့ဖြင့် တိတ်ဆိတ်နေသော အက်ပ်သည် ဈေးမကြီးပါ။ သုံးသည့်အတွက်သာ ကျသင့်သည် (hosting limits); အိပ်နေသော အက်ပ်သည် compute အတွက် မကုန်ပါ။ Billing ဘက်အကြောင်းကို database များကို အမှန်တကယ် သုံးသည်အလိုက် ငွေရှင်းခြင်း တွင် ရေးထားသည်။

ဖမ်းစရာမှာ ဤနှစ်ခုသည် သီးခြား အိပ်သည်၊ connection ဆိုသည်မှာ ဘာဖြစ်သည်ကို သဘောတူညီမှု မရှိပါ။

ရောဂါလက္ခဏာ: ပထမ ဝင်ကြည့်မှု နှေးခြင်း

အများစု server အက်ပ်များသည် connection pool ကို ထားသည်: database connection အနည်းငယ်ကို ပြင်ဆင်ထားပြီး request တိုင်းက connection အသစ် မဖွင့်ရသည်။ အမြဲနိုးနေသော အက်ပ်အတွက် မှန်ကန်သော ဒီဇိုင်းဖြစ်သည်။

အိပ်ခြင်းဖြင့် ဖြစ်ပျက်ပုံမှာ ဤသို့ဖြစ်သည်:

1. အက်ပ် run နေပြီး pool တွင် idle connection အချို့ ရှိသည်။
2. ဘယ်သူမျှ မဝင်ပါ။ အက်ပ်၏ စက်သည် ရပ်သွားသည် — pool ကို မပျက်ဘဲ ခဲထားသည်။
3. Database အိပ်သွားပြီး connection တိုင်း၏ အခြားဘက်ကို ချလိုက်သည်။
4. ဧည့်သည် ရောက်လာသည်။ အက်ပ်သည် ရှိသည့်အတိုင်း နိုးလာပြီး သူ့သိသော်လည်း မရှိတော့သော connection များကို ကိုင်ထားဆဲ ဖြစ်သည်။
5. Pool က ထို connection တစ်ခုကို ပေးသည်။ သေနေကြောင်း သိရန် ကြိုးစားပြီး စောင့်ရသည် — ထို့နောက်မှသာ စွန့်လွှတ်နိုင်သည်။

Spring Boot အက်ပ်တွင် သေနေသော connection များကို စစ်ဆေးရာတွင် ပထမ request ကို ၁၀ စက္ကန့်ခန့် ပိတ်ထားပြီး နောက်မှ "Connection is not available" ဖြင့် ကျရှုံးသည်။ ဧည့်သည်အတွက် ဆိုဒ်က ရပ်နေသလို ထို့နောက် error ပြသည်။

Spring အက်ပ်များ ဘာကြောင့် ပိုဆိုးသလဲ

Spring Boot သည် လူကြိုက်များသော Java framework ဖြစ်ပြီး ပုံသေအားဖြင့် HikariCP ဟုခေါ်သော connection pool ကို သုံးသည်။ Spring သည် ထို pool ကို settings မှ သတ်မှတ်နိုင်ပြီး idle connection မည်မျှ ထားမည်ကိုလည်း ပါဝင်သည်။

သို့သော် Mythex က database တစ်ခုစီကို DATABASE_URL တစ်ခုတည်းအဖြစ် postgresql://user:pass@host/db ပုံစံဖြင့် ပေးသည်။ Spring သည် ထိုပုံစံကို တိုက်ရိုက် ဖတ်၍ မရပါ။ ထို့ကြောင့် Mythex ပေါ်ရှိ Spring အက်ပ်များသည် URL ကို parse လုပ်ပြီး ကိုယ်ပိုင် pool ကို ကုဒ်ဖြင့် တည်ဆောက်ခဲ့ကြသည်။ လက်ဖြင့် တည်ဆောက်ထားသော pool သည် Spring ၏ spring.datasource.* settings များကို လျစ်လျူရှုသည်။ မှန်ကန်သော pool settings ကို လူတစ်ယောက်က သိပြီးဖြစ်သော်လည်း အကျိုးသက်ရောက်မည့် နေရာ မရှိခဲ့ပါ။

ပြင်ဆင်ချက် ၁: Spring သုံးနိုင်သော settings

Project တွင် database ရှိသည့်အခါ Spring ဖတ်နိုင်သော environment variables များကိုလည်း ယခု ပေးသည်:

• SPRING_DATASOURCE_URL၊ SPRING_DATASOURCE_USERNAME နှင့် SPRING_DATASOURCE_PASSWORD၊ DATABASE_URL မှ ပြောင်းထားသည် (URL က မဖော်ပြသမျှ SSL လိုအပ်သည်)။
• အိပ်ပျော်ပြီးနောက်လည်း ရပ်မသွားသော pool settings:

Idle connection ဘာမျှ မဖွင့်ထားသဖြင့် နိုးလာသော အက်ပ်သည် သေနေသော connection များကို ဖြတ်မသွားဘဲ connection အသစ် တစ်ခုကို ဖွင့်သည်။

ဤ variable များ ရှိသောအခါ Spring သည် pool ကို ကိုယ်တိုင် သတ်မှတ်ပြီး settings များ အကျိုးသက်ရောက်သည်။ Project က ကိုယ်တိုင် သတ်မှတ်ထားသော အရာသည် အမြဲ အနိုင်ရသည်၊ ကျန်သည်များကိုသာ ဖြည့်ပေးသည်။ Spring မဟုတ်သော အက်ပ်များသည် variable များကို လျစ်လျူရှုသည်။

နီးပါး အလုပ်မလုပ်တော့သော အသေးစိတ်

Spring သည် environment variable များကို settings သို့ မြေပုံဆွဲရာတွင် စည်းမျဉ်းကို မှားရလွယ်သည်။ minimum-idle ကို SPRING_DATASOURCE_HIKARI_MINIMUMIDLE ဟု ရေးရမည် — dash များ ဖယ်ထုတ်ပြီး စကားလုံးများ ပေါင်းထားသည်။ SPRING_DATASOURCE_HIKARI_MINIMUM_IDLE ဟု ရေးလျှင် ပိုသဘာဝကျဟု ထင်ရသော်လည်း မတူသော မရှိသော setting (minimum.idle) သို့ ရောက်သွားပြီး တိတ်တဆိတ် လျစ်လျူရှုခံရသည်။

ထိုသို့သော အမှားမျိုးသည် review တိုင်းကို ကျော်ဖြတ်နိုင်ပြီး production တွင် ဘာမျှ မလုပ်ပါ။ ထို့ကြောင့် test တစ်ခုက တန်ဖိုးများ သတ်မှတ်ထားမှုကို စစ်ဆေးသည်၊ variable မည်သည်မျှ underscore ဖြင့် ခွဲသော ပုံစံ မသုံးကြောင်းကိုလည်း စစ်ဆေးသည်။

ပြင်ဆင်ချက် ၂: အခြား stack အားလုံး

Spring သည် pool ရှိသော တစ်ခုတည်း framework မဟုတ်ပါ။ ဘာသာစကားတိုင်းရှိ library တိုင်းကို ကြိုတင်ပြင်ဆင်၍ မရပါ။ ထို့ကြောင့် Mythex agent — သင့်အက်ပ်ကို ရေးသော AI — သည် stack မည်သည်ဖြစ်ဖြစ် ယခု standing ညွှန်ကြားချက် ရရှိသည်: publish လုပ်ထားသော အက်ပ်များနှင့် ၎င်းတို့၏ database များသည် idle ဖြစ်လျှင် အိပ်သည်၊ ထို့ကြောင့် ဖွင့်ထားသော connection သည် နောက် request တွင် သေနေနိုင်သည်။ Agent သည်:

• Idle database connection မဖွင့်ထားပါ သို့မဟုတ် အသုံးမပြုမီ တစ်ခုချင်းစီကို စစ်ဆေးပါ၊
• Connection error တွင် တစ်ကြိမ် ပြန်ကြိုးစားပါ၊ နှင့်
• DATABASE_URL ကို parse ၍ ကိုယ်ပိုင် pool မတည်ဆောက်ဘဲ ပလက်ဖောင်းက environment တွင် ပေးထားသော database settings ကို သုံးပါ။

နောက်ဆုံးအချက်က ပြင်ဆင်ချက် ၁ နှင့် ပိတ်ပေးသည်: ပေးထားသော settings ဖြင့် တည်ဆောက်သော အက်ပ်သည် sleep-safe configuration ကို အလိုအလျောက် ရရှိသည်။

ရလဒ်

ကျွန်ုပ်တို့ run သော hosting ပလက်ဖောင်းပေါ်တွင် တိုင်းတာခြင်းဖြင့် နိုးပြီးနောက် ပထမ request သည် ၁၂.၇ စက္ကန့်မှ ၂.၃ စက္ကန့် သို့ ပြောင်းခဲ့သည်။

ကျွန်ုပ်တို့ ရရှိခဲ့သည့်အရာ

• Sleep ဖြစ်သော အလွှာတိုင်းသည် ဘာ ကျန်ရစ်မည်ကို သဘောတူရမည်။ အေးသော အက်ပ်နှင့် အိပ်သော database တို့သည် သင့်တော်သော ရွေးချယ်မှုများ ပြုလုပ်ခဲ့သည်။ အတူတကွ အက်ပ်သည် မှန်ကန်မှု မရှိတော့သော state ကို ကိုင်ထားပြီး နိုးလာသည်။
• အမြဲနိုးနေသော server များအတွက် ဒီဇိုင်းထားသော ပုံသေများသည် zero သို့ scale လုပ်သော အက်ပ်များနှင့် မကိုက်ညီပါ။ Connection များကို နွေးထားခြင်းသည် ကောင်းသော်လည်း ပတ်ဝန်းကျင် အားလုံး အေးသွားသည်အထိသာ ဖြစ်သည်။
• Framework များကို ၎င်းတို့ ဖတ်နိုင်သော format ဖြင့် data ပေးပါ။ URL တစ်ခုသည် ကျွန်ုပ်တို့အတွက် ရိုးရှင်းသော်လည်း Spring အက်ပ်တိုင်းကို ကိုယ်ပိုင် pool ကို လက်ဖြင့် ရေးစေခဲ့သည်။
• Setting တစ်ခု framework ဖတ်သော အမည်အတိုင်း ရေးထားခြင်းကို စမ်းသပ်ပါ။ အမည်မှား၍ မှန်သော တန်ဖိုးသည် တိတ်တဆိတ် ဘာမျှ မလုပ်ပါ။

Mythex ပေါ်ရှိ database အကြောင်း ပိုသိလိုပါက database docs နှင့် Postgres ဆိုသည်မှာ ဘာလဲ ကို ကြည့်ပါ။