วันอังคารที่ 22 สิงหาคม พ.ศ. 2560

HHVM เทคโนโลยีที่ชาว Server Side ควรเริ่มศึกษาไว้ ณ บัดนาว

HHVM เทคโนโลยีที่ชาว Server Side ควรเริ่มศึกษาไว้ ณ บัดนาว

ก่อนอื่น ขอสลับโหมดท่านผู้อ่านก่อน เนื้อหาตอนนี้มันสัพเพเหระตั้งแต่ทำอาหารยังเขียนโปรแกรม ยังไงแปะ Rating ก่อนเลย Blog นี้ Geek นะ ! โป้ง !
ตั้งแต่ node.js เกิดมา PHP ก็หมดความเซ็กซี่ลงไปเรื่อยๆจาก Performance ที่ยังไงก็สู้ node.js ไม่ได้ ในขณะที่เว็บทุกวันนี้ก็เน้น Scalable ทุกหยด Performance นั้นถือเป็นสิ่งสำคัญ เงินทั้งนั้นนะเว้ยเฮ้ย คนก็เลยหันไปเล่น node.js กันเยอะขึ้นเรื่อยๆ เกิดหนทางการพัฒนาแตกออกมาเป็นร้อยสายกว่าหมื่นกระบวนท่า เกิดเป็น Stack ต่างๆขึ้นมาให้เลือกเพียบ เช่น MEAN, MEANJS, CompoundJS, Sails ผนวกกับ Add on ประกบหน้าประกบหลังประกบบนประกบล่างเอบีเอบีสตาร์ท นับแล้วศึกษายังไงก็ไม่หมด อ้วกพุ่งกันไปเลยทีเดียว จึงไม่ต้องแปลกที่จะได้เห็น Graph นี้จาก Github

Javascript ครองโลกกกกก ทางด้าน PHP ตกมาหน่อยนึง สภาวะทรงตัวมาหลายปีละ ส่วน Ruby ... ดิ่งงงงง (แต่ก็ยังเยอะกว่าโปรเจค PHP อยู่ดี)
ทางด้าน PHP เห็นแบบนี้ก็คิดว่าคงไม่ดีแน่ จึงมีการพัฒนาแนวทางออกมาอยู่หลายต่อหลายอย่าง ตั้งแต่การอัพเกรด Performance ที่ตัว PHP Runtime เอง การอัพ APC หรือยัด APC Replacement อย่าง Zend OPCache รวมถึง Native Extension อย่าง PhalconPHP ที่ไปทำคำสั่งต่างๆในระดับ Native เลย
แต่สุดท้าย จนแล้วจนรอด ก็ยังไม่มีท่าไหนที่สามารถสู้ node.js ได้อยู่ดี (แต่ Phalcon นี่ใกล้ที่สุดละ ถือว่าเจ๋งไม่น้อยเลยหละ) ข้อดีข้อเดียวของมันพักหลังนี้คือเขียนง่าย หาโปรแกรมเมอร์ทำง่าย แต่ก็ Trade Off กับ Performance ที่ไม่เหมาะกับงานสเกลใหญ่
แต่แล้ว นายมาร์ค ซักเกอร์เบอร์ค ก็ขี่ม้าขาวมาช่วยมวลมนุษย์เหล่า Server Side Guy
วันนี้มีโอกาสนั่งเล่น HHVM นิดหน่อย ตอนแรกก็ไม่อะไรหรอก แต่พอได้ลองเท่านั้นแหละ ... หิวข้าวเลย ยังไม่ได้กินตั้งแต่เช้า เอาแต่ทำงาน T_T
ไม่ใช่!
พอมีโอกาสได้ลองก็ติดลม ลองหนักขึ้นเรื่อยๆลึกลงเรื่อยๆจนเห็น Potential อันยาวไกลของ HHVM ผุดขึ้นมาเป็นฉากๆเลยทีเดียว อารมณ์ว่ามันสามารถเปลี่ยนโลกได้เหมือนที่ node.js เปลี่ยนมาแล้วรอบนึง จนคิดว่ามันเป็นเรื่องสำคัญมากจนต้องมาเขียน Blog เลย (ระดับความสำคัญนี่พอๆกับไข่ออนเซ็นเลยนะ)
แต่นี่ยังศึกษาไม่นานมาก เลยขอไม่ลงลึกมากนะครับ เอาแค่คร่าวๆพอเห็นภาพก่อนละกันโนะะะะ
กำเนิด HHVM และหลักการทำงาน
จุดกำเนิดของ HHVM คือ HipHop PHP Compiler (HPHPc) ระบบอันเลื่องชื่อของ Facebook ที่คอมไพล์โค้ดภาษา PHP ออกมาเป็น Executable Binary จนทำให้ทุกอย่างทำงานเร็วมากและกิน Resource น้อยกว่าทั่วไปมาก (ก็มันเป็น Native นี่นา) จึงถูกใช้บนเว็บ facebook.com มาช้านานและช่วยประหยัดค่าใช้จ่ายของบริษัทไปได้เยอะมาก
แต่แล้ว HPHPc ถึงจะเทพปานนั้น แต่ก็มีปัญหาอยู่มากมาย หลักๆเลยคือไม่สนับสนุนภาษา PHP เต็มรูปแบบ บางคำสั่งก็ได้ บางคำสั่งก็ไม่ได้ รวมถึงคำสั่งที่ใช้บ่อยในการเขียน Advance PHP Programming ในยุคหลังอย่าง create_function, eval ก็ใช้งานไม่ได้เช่นกัน ผนวกกับปัญหาอีกมากมายก่ายกอง เช่นกิน Resource ในการคอมไพล์มาก ดีบั๊กยาก บลาๆๆๆ จนส่งผลให้ท้ายที่สุด Facebook ก็ประกาศเซย์กู้ดบายกับเจ้า HPHPc ไป
แล้ว Facebook ก็หายไปแว้บนึง โผล่มาอีกทีกับความเท่สุดบรรยาย ด้วยการเปิดตัว HHVM (HipHop Virtual Machine) ที่ทำตัวเป็น Interpreter ทำงานแทน PHP Interpreter เช่นพวก php5-fpm เลยโดยสมบูรณ์ ทำหน้าที่รับโค้ดเข้ามา แล้วแปลงเป็น Bytecode (HHBC) ก่อนจะแปลงเป็น Binary เพื่อรันแบบ Native อีกทีหนึ่งด้วย JIT ผลคือไม่ต้องมานั่งคอมไพล์ก่อนรันเพราะมันคอมไพล์แบบ Runtime ให้ แถมยังคงซึ่งประสิทธิภาพที่เหนือกว่า PHP ทั่วไปอย่างมหาศาล จากการที่มันเป็น Native และ I/O Non Blocking ล่าสุดประสิทธิภาพของมันแซง HPHPc ไปเป็นที่เรียบร้อยแล้วตั้งแต่ปีก่อน
ถ้าให้พูด Big Picture มันให้อารมณ์เหมือนเขียน node.js ด้วยภาษา PHP ยังไงอย่างงั้นเลย โดยผลไม่ใช่แค่ประสิทธิภาพการประมวลผลที่ดีขึ้น หากแต่ยังกิน Resource น้อยกว่ามากและรับ Concurrent ได้สูงกว่าหลายเท่าตัวอีกด้วย
และมันก็ถูกพัฒนาไปอย่างต่อเนื่องไม่หยุดหย่อน บั๊กทั้งหลายค่อยๆถูกกำจัดไปทีนิดๆ ฟังก์ชั่นต่างๆก็ได้รับการสนับสนุนเพิ่มขึ้นเรื่อยๆ พวก Framework ดังๆทั้งหลายก็ผ่านการเทสต์ไปเกือบหมดแล้ว เย้ ! (ลองอ่านผลการเทสต์ได้จาก http://hhvm.com/frameworks/)
ถามว่ามันจริงจังแค่ไหน? ก็ตอนนี้ Facebook ใช้ HHVM รัน facebook.com อยู่นี่แหละครับ
Hack Language
ไหนๆก็ทำ Interpreter/Runtime เองแล้ว Facebook ก็เลยใช้โอกาสนี้ สร้างโครงสร้างภาษาเพิ่มเติมจาก PHP ของตัวเองขึ้นมาพร้อมกับ Library เพิ่มเติมบางส่วน ชื่อว่า Hack Language ที่ทำให้การเขียนโปรแกรมด้วย PHP ที่ว่าง่ายแล้ว ง่ายขึ้นไปอีกและมีรูปแบบภาษาที่ Flexible น้อยลง (หรือเขียนผิดได้ยากขึ้นนั่นเอง) ทำอะไรได้อีกเพียบ ไม่ว่าจะเป็น Generic Classes/Methods (เช่น class Box<T>) พวก Collections (Vector, Set, Pair) ก็มีให้ใช้ แล้วก็ยังใช้ async await ได้ จากประโยชน์ของ I/O Non-Blocking นั่นเอง (อันสุดท้ายนี้ชอบมาก)
สำหรับ Hack Language ทาง Facebook กำลังพยายามดันอยู่อย่างเต็มที่ ลองไปอ่านเพิ่มดูกันได้ครับ ที่ http://hacklang.org/ =)
โค้ดบางส่วนยังคงใช้งานไม่ได้และใช้ Extension ร่วมกับ PHP เดิมไม่ได้
ถึงการสนับสนุนคำสั่งทั้งหลายจะใกล้เคียงกับ PHP 5.5 มากแล้ว แต่มันก็ยังไม่สมบูรณ์ซะทีเดียว ทำให้ยังมีบางคำสั่งที่ยังใช้งานไม่ได้ ต้องลองและทดสอบไปก่อน อย่างตอนนี้ที่เนยเทสต์เองก็พบว่าเนยย้ายเว็บส่วนใหญ่ที่ไม่ได้ซับซ้อนอะไรมากไปใช้ hhvm ได้เลย ไม่ต้องปรับเปลี่ยนอะไรทั้งสิ้น แต่ก็มีอยู่เว็บนึงที่แอบซับซ้อน มีเรียกคำสั่งโน่นนี่ ก็รันไม่ขึ้นเลย หน้าขาวๆ
ส่วนเรื่อง Extension ก็อาจจะเป็นอีกปัญหานึงเพราะ HHVM ไม่ได้ใช้ Codebase เดียวกันกับ PHP เดิม ส่งผลให้ Extension ที่เขียนมาเพื่อ PHP เดิม ไม่สามารถนำมาใช้กับ HHVM ได้เลย แต่เผอิญ HHVM ก็เปิดตัวมาสักพักนึงแล้ว ทำให้เริ่มมีคน Port Extension มาให้ HHVM ใช้กันแล้ว อยู่ใน github มีเพียบเลย แต่ถามว่าครอบคลุมเท่าตัวเดิมรึยัง? ก็ต้องยอมรับว่ายังครับ
Performance ไม่ได้ดีกว่าเสมอไป
นั่งอ่าน Benchmark เยอะแยะมากมายจนตาแฉะ พบว่า HHVM ไม่ได้เร็วที่สุดในทุกกรณี โดยอ่านมาหลายเว็บแล้วผลตรงกันคือ
ถ้าโค้ดทำงานไม่หนัก Performance จะแย่กว่า Zend OPCache แต่ถ้าโค้ดทำงานหนัก HHVM จะมี Performance ที่ดีกว่า
ซึ่งถึงจะแย่กว่าแต่ก็แย่กว่าไม่มาก เรียกว่าใกล้ๆกัน โดยเว็บนี้เป็นเว็บที่เห็นผลได้ชัดที่สุด Symfony benchmark using HHVM
โค้ดไม่หนักก็เช่น Hello World ส่วนโค้ดหนักก็เช่น Fibonacci ที่ทำผล Benchmark ต่างกันกระจุยกระจายหลายสิบเท่า
ส่วนเว็บนี้เป็นอีกผลการทดลอง PHP’s HipHop outperforms PHP 5.5 with Zend OPCache and Nginx by 15-20 times โดยได้ผลได้น่าสนใจว่า HHVM สามารถรับ Request per second ได้มากกว่า OPCache ถึง 20 เท่า โดยใช้เวลาในการประมวลผลเพียง 8% ของ OPCache เท่านั้นเอง
แต่โดยเฉลี่ยแล้ว Performance ของ HHVM จะดีกว่า "อย่างมีนัยสำคัญ" เพราะโค้ดมักจะซับซ้อนเกินจุด Hello World อยู่แล้ว
แต่ความหนักของโค้ดก็ไม่ใช่ปัจจัยเดียวที่มีผลต่อ Performance ...
โครงสร้างโค้ดมีผลต่อ Performance
ผลการทดสอบของเว็บ PHP 5.5 vs HHVM vs Node.js Benchmark part 2 และ PHP 5.5 vs HHVM vs Node.js Benchmark part 3 ก็เป็นอีกอันที่น่าสนใจ
เป็นการทดสอบโค้ดเดิม โดยอันนึง Wrap อยู่ใน function ส่วนอีกอันรันออกมาข้างนอก ผลการทดลองออกมาคือ ในเคสที่ไม่ได้ Wrap ใน function ผล Response Time ออกมาแย่ในระดับเลวร้าย แย่กว่า php5.5 ถึง 5 เท่า และแย่กว่า node.js ถึง 36 เท่า แต่ เคสที่ Wrap โค้ดอยู่ใน function ประสิทธิภาพกลับดีขึ้นทันที 40 เท่า และเทียบประสิทธิภาพได้เท่ากับ node.js เลย
จะเห็นได้ว่าแค่เขียนโค้ดต่างกัน ผลการทำงานก็ประสิทธิภาพต่างกันแล้ว อันนี้ต้องเรียนรู้ Best Practise และเข้าใจตัว Interpreter ว่ามันคอมไพล์โค้ดเป็น Bytecode อย่างไร
ไม่รู้ว่าตรงนี้ทางทีม HHVM แก้ไขหรือยัง ถ้าแก้ไขแล้วก็อาจจะสบายหน่อย แต่ถ้ายังก็คงต้องเรียนรู้เพิ่มเติมครับ
ถึงเวลาสลับไปใช้ HHVM หรือยัง?
HHVM มีการใช้งานจริงแล้วในหลายพื้นที่ รวมถึง Facebook แต่อย่างที่บอกว่า HHVM มันยังแทนที่ PHP ตัวเดิมไม่ได้แบบ 100% ดังนั้นมีหลายปัจจัยมากที่ต้องพิจารณาก่อนจะสลับไปใช้ HHVM อย่างจริงจัง เช่น
1) โค้ดสนับสนุน 100% หรือไม่ (อันนี้สำคัญมาก)
2) Performance ดีขึ้นหรือไม่ (จากเหตุผลด้านบน โค้ดต่าง ประสิทธิภาพต่าง)
ถ้าเทสต์ทุกอย่างผ่าน นาทีนี้ผมเชียร์ให้ "ลอง" สลับไปใช้ดูนะ เพราะถือว่าเสถียรกว่าแต่ก่อนมากแล้ว สามารถใช้ใน Production ได้แล้วระดับหนึ่งเลย แต่ก็ต้องทำตัวให้ชินกับคำคำนึงไว้ด้วย
Segmentation Fault
เมี่ยงเอ้ย ตามมาหลอกหลอนอีกละ - -
ตอนนี้ http://nuuneoi.com  http://nichieme.com (Wordpress) ก็สลับมาใช้ HHVM เป็นที่เรียบร้อยแล้วครับ ใช้ทุกอย่างได้สมบูรณ์ดี ไม่ต้องเปลี่ยนโค้ดเลย และก็เป็นไปตามที่เค้าโม้เลย มันเร็วขึ้นและกิน Resource น้อยลงจริงๆ
ทำไม HHVM ถึงสำคัญและคนทำด้าน Server Side ควรจะศึกษาไว้ตั้งแต่ตอนนี้?
เราสลับไปใช้ node.js ก็เพราะประสิทธิภาพที่ดีขึ้น มัน Solve Pain ของ Server Side Programmer เรื่องของประสิทธิภาพได้เป็นอย่างดี แต่ก็ต้องแลกกับการมานั่งปวดหัวและ Handle Error ต่างๆนานา เกิดเป็น Pain ใหม่ขึ้นมา
แต่พอ HHVM เกิดขึ้นมา มัน Solve Pain ครบเลย ทั้งเรื่องประสิทธิภาพและเรื่องความง่ายของภาษา ไม่ต้องมานั่งปวดหัวเรื่องการ Handle Error หรือเรื่อง Server จะล่มมั้ยอีกต่อไป ตอบโจทย์ครบทุกอย่างที่ Server Side Programming แบบเน้นประสิทธิภาพต้องการแล้ว ตอนนี้ถ้าจะขาดก็แค่เรื่องของ Extension เท่านั้นเอง (ซึ่ง Community ก็ขยันปั่นออกมาอย่างไม่หยุดยั้งตอนนี้ ใครอยากร่วมด้วยช่วยปั่น ลองดู Extension API ได้)
หลังจากได้เล่นและทดสอบแล้ว ส่วนตัวเชื่อว่า HHVM จะเป็น Base ของการพัฒนา Framework ในสาย PHP ต่อจากนี้อีกยาวไกล จะมี Extension ออกมามากมาย จะมีเป็น Dependency เพื่อ Install อัตโนมัติเหมือนพวก bower อะไรออกมา โดยประสิทธิภาพสามารถฟาดฟันกับ node.js ได้อย่างสบายๆ ด้วยพลังการเขียนที่น้อยกว่ามาก
และส่วนตัวเชื่อว่า HHVM มีอนาคตที่รุ่งเรืองในสายงานนี้มากๆครับ แบบว่านานๆจะได้ลองอะไรแล้วรู้สึกท้องไส้ปั่นป่วน เห็นภาพอนาคตว่าจะเป็นยังไง นี่มันคือจุดเปลี่ยนของโลกเลย ไรงี้ (เว่อร์มะ แต่ก็รู้สึกตามนั้นจริงๆ)
ดังนั้น จับไว้ครับ
โลกหมุนไว ลูกต้องก้าวให้ทัน
แต่ก่อน PHP ฮิตมาก ไปๆมาๆ node.js ตอนนี้ฮิตมาก (แต่ก็หาโปรแกรมเมอร์ทำได้ยากเหลือเกิน) แล้วตอนนี้ PHP ก็กำลังจะกลับมามีบทบาทเพิ่มอีกแล้ว
วันก่อนมีคนมาถามว่า "จะจับเทคโนโลยีไหนดี มันไปไวเหลือเกิน" ก็คงต้องขอตอบว่า อย่ายึดติดกับสิ่งใด โลกนี้มันหมุนไวมาก สิ่งที่เกิดมาตอนนี้แล้วช่างหรูหราฟู่ฟ่า มันอาจจะกลายเป็นสิ่งไร้ค่าในอีก 3 เดือนข้างหน้าก็เป็นได้ ดังนั้น ... Fast Adopter wins ครับ
DONE is better than PERFECT
และมีคนถามอีกว่าจะใช้ node.js หรือ PHP หรือจะไป django หรือจะ RoR ดีครับ
จริงอยู่ว่ามันมีเรื่องของประสิทธิภาพอยู่ แต่จากประสบการณ์นะ คนที่มานั่งกังวลว่าจะใช้เทคโนโลยีอะไรแล้วไปจับสิ่งที่ตัวเองไม่ถนัดเพียงเพื่อ Performance สุดท้ายจะพบกับทางตันและทำงานออกมาให้เสร็จไม่ได้
แล้วมันจะมีประโยชน์อะไรที่ทำไม่เสร็จและงานไม่ได้ Launch?
DONE is better than PERFECT
จับที่ตัวเองถนัดและลุยมันให้เสร็จเป็นสิ่งที่สำคัญที่สุด จากนั้นค่อยพัฒนาตัวเองและทำให้มันดีขึ้นหรือจะเขียนใหม่ก็ว่ากันอีกที ก็ต้อง Balance ด้วยเน้อ ^_^

Reference:
ที่มา:https://nuuneoi.com/blog/blog.php?read_id=671

ไม่มีความคิดเห็น:

แสดงความคิดเห็น

Set MongoDB in the windows path environment

  Let’s set MongoDB in the windows environment in just a few steps. Step 1: First download a suitable MongoDB version according to your mach...