Learn from Node.js Production on server

App အသစ် တစ်ခုအတွက် backend ကို Node.js ကို Express JS framework အသုံးပြုပြီးရေးထားတယ်။ Database ကို Mongodb ကို သုံးထားတယ်။ လက်ရှိတော့ ဘာ data မှ ထွေထွေထူးထူး မရှိသေးသလို Data တွေ အများကြီး ရှိလာစရာလည်း အကြောင်း မရှိဘူးထင်တယ်။ Node.js ကို production အဆင့်ကို ပို့ရတာ ထင်ထားတာ ထက် ပိုပြီး ရှုပ်တယ်။ PHP နဲ့ ယှဉ်ရင်တော့ မလွယ်ကူလောက်တာ အမှန်ပဲ။

လက်ရှိ Node.js ကို Nginx နဲ့ proxy ကို သုံးပြီး run ထားတယ်။ Real time web socket app တွေဆိုရင်တော့ IP တစ်ခု app တစ်ခုထားတာ ပိုကောင်းမယ်ထင်တာပဲ။ အခုတော့ IP တစ်ခုတည်းကို nginx နဲ့ proxy ခံပြီးသုံးထားရတော့ memory usages က များနေတယ်။ လက်ရှိ Server မှာ PHP FPM နဲ့ PHP ကို run ထားပြီးတော့ Node.js App ၂ ခုကိုလည်း Nginx နဲ့ run ထားပါတယ်။ PHP FPM ဟာ PHP website အားလုံးအတွက် server process တစ်ခု နဲ့ ပဲ အလုပ်လုပ်ပါတယ်။ Node.js ကတော့ App တစ်ခုအတွက် process တစ်ခု အလုပ်လုပ်ထားပါတယ်။ PHP FPM ဟာ config ပေါ်မှာမူတည်ပြီး server process ဘယ်လောက် run မယ်ဆိုတာကို သတ်မှတ်ထားလို့ရပေမယ့် Memory က 512 MB ပဲရှိတဲ့အတွက် တစ်ခုပဲ run ထားရပါတယ်။ Node.js ကတော့ အဲလို လုပ်မရတဲ့အတွက်ကြောင့် သို့မဟုတ် ကျွန်တော် မလုပ်တတ်သေးကြောင့် memory က ပိုကုန်နေပါတယ်။ Node.js ဟာ PHP ထက်တော့ ပိုမြန်ပါတယ်။ Memory လည်း ပိုစားပါတယ်။

တကယ်လို့ Memory 2 GB လောက်ရှိပြီးတော့ CPU 2 Core လောက်ရှိရင်တော့ 2 Nginx process နဲ့ 2 PHP FPM server process run ထားလိုက်ရင် လက်ရှိ Node.js လို မြန်သွားပါလိမ့်မယ်။ Node.js ကို production ပိုင်းကိုရွှေ့တော့ အဓိက ပြဿနာက memory ပဲ။ Node.js ကို ကျွန်တော်က server မှာ compile လုပ်ပြီးတော့ update လုပ်နေကြဆိုတော့ memory မလောက်တာ ခဏခဏ ဖြစ်သွားတယ်။ လက်ရှိ Server မှာ Mongodb , MySQL , 2 Node.js App , PHPFPM ,Nginx , Trasmission စတာတွေ run ထားတာကြောင့် Memory က 90 KB ပဲ လွတ်ပါတော့တယ်။ Optimize လုပ်ဖို့ အချိန် မပေးနိုင်သေးတာကြောင့်လည်း ပါတာပေါ့။

Node.js ကို forever နဲ့ run ထားပြီး error တက်ပြီး ပိတ်သွားရင် အလိုအလျောက် ပြန်တက်လာအောင် လုပ်ထားတယ်။ Node.js PHP နဲ့ မတူတာကတော့ Error တစ်နေရာ တက်သွားရင် process တစ်ခုလုံး ပိတ်သွားတာပဲ။ ဥပမာ ။။ ကျွန်တော် db object ရှိမရှိ မစစ်ပဲ db.collection(‘user’); ဆိုပြီး ခေါ်လိုက်တယ်ဆိုပါဆို့ , PHP မှာဆိုရင် error ပဲ တက်ပေမယ့် node.js မှာတော့ error တက်ပြီး ပိတ်သွားပါလေရော။ Node.js ရေးတဲ့အခါ PHP ထက်ပိုပြီး error condition တွေကို ပိုပြီး သတိထားပြီးရေးဖြစ်တဲ့ အကျင့်တော့ ရှိလာတယ်။ ဘယ်အချိန်မှာ error တွေ ဘယ်လိုတတ်နိုင်သလဲဆိုတာကို ပိုစဉ်းစားဖြစ်တယ်။ တကယ်လို့ အဲဒီ အကျင့်သာ မရှိရင် production မှာ process က ရပ်လိုက် run လိုက်နဲ့ ကြာလာရင် server load က အရမ်းများလာပါလိမ့်မယ်။

နောက်ထပ် ပြဿနာက mongodb ပါပဲ။ mongodb lock ကြောင့် တစ်ခါတစ်လေ database နဲ့ ချိတ်မရတာတွေ ဖြစ်တတ်တယ်။ ဥပမာ။။ ကျွန်တော် mongodb ကနေ data ထုတ်တာနဲ့ အခြား collection မှာ insert ထည့်တာကို တပြိုင်တည်း လုပ်တယ်ဆိုပါဆို့။ db connection ဖွင့်တဲ့ အခါမှာ lock ဖြစ်နေတဲ့အတွက်ကြောင့် တစ်ခါတစ်လေ connection မရတာ ရှိတတ်တယ်။ အဲဒီ အတွက်

 db.authenticate(username, password, {authdb: 'admin'}, function(err, result) {
 });

ဆိုပြီး ပြောင်းရေးထားပေးရင်တော့ အဆင်ပြေပါတယ်။ authdb သာ မပါခဲ့ရင် lock ကြောင့် connection ချိတ် မရတာ ဖြစ်တတ်ပါတယ်။ Database ကို ဖွင့်ပြီးရင် ပြန်ပိတ်ဖို့ မမေ့ဖို့လိုပါတယ်။ Server ပေါ်ကို file တင်တဲ့အခါမှာ လက်ရှိ forever process ကို ပိတ်။ ပြီးမှ ပြန် run စတာတွေကို လုပ်ရပါတယ်။ အဲလိုမျိုး manual မလုပ်ချင်ရင်တော့ /etc/init.d/ အောက်မှာ service တစ်ခု ဝင်ရေးဖို့လိုမယ်။ ပြိးရင် Git ကို server မှာ ထောင်ထားပြီးတော့ git hook ဖြစ်တဲ့ pre-receive မှာ အဲဒီ service ကို ပြန်ပိတ်ဖို့အတွက် ရေးထားရပါတယ်။ ပြီးရင် post-receive မှာ git checkout လုပ်တာနဲ့ service ကို ပြန်ပြီး ဖွင့်တာ ရေးပေးလိုက်ရင်တော့ client ကနေ git ကို push လုပ်လိုက်တိုင်း အလိုလို service ကို ပိတ် ၊ git checkout လုပ် ၊ ပြီးရင် server ပြန်ဖွင့် စတာတွေ အလုပ်လုပ်ပေးသွားပါတယ်။ ssh နဲ့ ဝင်ပြီးတော့ ဘာမှ manual လုပ်နေစရာမလိုတော့ဘူးပေါ့။ အဲဒီ အကြောင်း အသေးစိတ်ကိုတော့ post တစ်ခုရေးဖို့ အစီအစဉ် ရှိပါတယ်။

Node.js production သွားရင်တော့ ကျွန်တော့် အတွက် memory က ပဲ အဓိက ပြဿနာဖြစ်နေတယ်။ ကျန်တာကတော့ git setup လုပ်ရတယ်။ nginx မှာ proxy pass လုပ်ရတယ်။ ဒီလောက်ပါပဲ။ Node.js ကို production အဆင့်လုပ်တဲ့ အခါမှာ server မှာ ဘယ်လို လွယ်အောင် deploy လုပ်လို့ရမလား စဉ်းစားရင်နဲ့ git hook တွေ သိသွားရတာကတော့ အမြတ်ပါပဲ။

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.