เนื่องจากว่าอาทิตย์ที่ผ่านมาผมคลุกคลีอยู่กับการปรับปรุงประสิทธิภาพของ MySQL ซึ่งการทำครั้งนี้ก็ประสบความสำเร็จไปได้ดี โดยผมตั้งใจจะนำความรู้มาให้กับ คนรุ่นใหม่ที่คิดการใหญ่ แต่ติดปัญหา Database ช้ารองรับคนเข้าไม่ได้เยอะ หรือเจอปัญหาเฉพาะทางอย่างของผมที่มีการอัพเดตอยู่ตลอดเวลา Table บวม 16gb ทำยังไงให้มันเร็วได้บ้าง โดยวันนี้ผมขอ Scope เฉพาะเรื่องการค้นหาปัญหาก่อน ที่จะ Tuning ดังนั้น ถึงแม้เราจะมีเครื่องที่มีประสิทธิภาพแค่ไหน แต่ถ้าเราไม่รู้สาเหตุที่แท้จริงก็ทำให้เร็วขึ้นไม่ได้ เครื่องมือสำคัญมีดังนี้

• phpMyAdmin
• MySQLTuner
• MySQL Tuning Primer
• Optimize only fragmented tables in MySQL

โดย 2 ตัวล่างเราต้องมี SSH เพื่อเข้าไปสั่งมันรันด้วย perl กับ sh ได้นะครับ โดยวิธีใช้ก็เรียกชื่อไฟล์นั้นตรงๆ (ข้ออนุญาติไม่สอนแต่มันไม่ยากเลยนะ ) เสร็จแล้วเราจะเจออะไรทำนองแบบใน ลิงค์นี้ ทีนี้เราต้องทำความเข้าใจว่าทำไม Query เราช้าเป็นเพราะอะไร ดังนั้นก่อนจะสำรวจตัวเองคุณต้องเข้าใจเรื่องหลักๆของ MySQL หรือ RDBMS ทั่วไปและ Server กันก่อน ผมจะขอรวบรัดใครอยากรู้ลึกๆไปศึกษากันต่อนะครับ

• เวลาเรา Query ข้อมูลปกตินั้นก็เหมือนเรามีกองเอกสารที่ไม่ได้มีการจัดเรียงวางกองๆไว้ เวลาจะหาเราก็เลยต้องรื้อถึงจะเจอ ทำให้ไม่มีประสิทธิภาพ
• ถ้าเรานำเอกสารมาเรียงๆก็สามารถถูกหาได้ง่ายขึ้นกว่ากองเอกสารมั่วๆ สิ่งนี้ใน MySQL เรียกว่า “Optimize Table” โดย Script ที่ผมนำมาใช้คือ Optimize เฉพาะ Fragment หรืออันที่ไม่ได้มีการเรียงข้อมูล ซึ่งเราจะพบได้ง่ายมากใน Table ขนาดใหญ่ ยังไงก็ระวังกันนิดหนึ่งคือถ้าไป Optimize Table ใหญ่ก็เสียเวลาหน้าดู
  
• ต่อให้เรียงแล้วแต่ถ้าเราอยากจะหาเอกสาร ABC ได้ง่ายขึ้นเราก็จะแปะ PostIt สีๆให้ออกมาข้างๆหรือใส่ที่คั่นหนังสือใน DB เราเรียกว่า “Index”
• แต่การจะหยิบข้อมูลเอกสารพร้อมๆกันหลายๆอันได้นั้นจะต้องมีความจำที่เพียงพอว่าแต่ละเอกสารนั้นอยู่ที่ไหน (Index อยู่ไหน) ทำให้ต้องใช้ความจำเข้ามา แล้วถ้าเราจำที่อยู่ของแต่ละเอกสารนั้นไม่ได้ เราก็ต้องค่อยๆเปิดทีละกองสองกอง (Key Buffer < Key Index ) ทำให้ช้าลง
• อีกเรื่องที่ทำให้ช้าได้คือ “พื้นที่โต๊ะไม่พอ” เหมือนกองเอกสารที่เราเก็บใส่แฟ้มแล้วไปว่างไว้ที่อื่น แต่ไม่ใช่บนโต๊ะเวลาจะนำมาใช้ก็ต้องเดินไปหยิบ ดังนั้นถ้าโต๊ะเราสามารถเก็บกองเอกสารทั้งหมดได้ เราก็ไม่ต้องเดินไปหยิบพอเต็มก็ทำให้เสร็จ แล้วก็เดินไปหยิบใหม่ นั้นเป็นที่มาของ “tmp_table_size”
• ส่วนตัวแปรอื่นๆที่มีผลในการทำเอกสารนั้นประกอบด้วย การอ่านเอกสาร (read_buffer_size) , การเรียงเอกสาร (sort_buffer_size) , การรวมเอกสาร (join_buffer_size) และการอ่านเอกสารที่สุ่มมา (read_rnd_buffer_size) โดยอันสุดท้ายมักจะเยอะขึ้นถ้ามีการ ORDER BY เยอะๆ
• สุดท้ายการจะทำงานได้เร็วคุณต้องทำงานเป็นทีมดังนั้น อย่าลืมจ้างพนักงานเพิ่ม​โดยต้องจ่ายเป็นเงินเดือน (CPU/Mem) โดยพนักงานมีชื่อเรียกใน DB ว่า (thread_concurrency) ถ้าเราอยากให้ผู้ช่วยเก่งๆ ก็ต้องฝึก การอ่านเอกสาร (read_buffer_size) , การเรียงเอกสาร (sort_buffer_size) , การรวมเอกสาร (join_buffer_size) และการอ่านเอกสารที่สุ่มมา (read_rnd_buffer_size) ซึ่งยิ่งพนักงานเก่งก็ต้องยิ่งจ่ายแพง (จ่ายแพงโดยเฉพาะ Memory)

หลักๆการ Tuning MySQL ก็จะมีเรื่องประมาณนี้ครับ โดยเราไปดูวิธีตรวจสอบว่าส่วนไหนของระบบเราช้ากันครับ โดยจะเป็นภาษาเทคนิค ถ้าฟังไม่เข้าใจก็ขออภัยนะครับ >.<

จบไปแล้วกับการอธิบายวิธีดูว่าส่วนไหนช้าและตัวแปรแต่ละตัวใน my.cnf เอาไว้ทำอะไร โดยผมเอาต้นแบบ config มาจาก Custom MySQL for ensure maximum performance ครับ โดยเท่าที่ลองดู Config แล้วมันเหมาะสำหรับเว็บทั่วไป , Blog , Webboard อะไรทำนองนี้ซึ่งข้อมูลแต่ละ Row ไม่ได้มีขนาดใหญ่มาก และไม่ได้ใช้ Fulltext แล้วเน้นไปที่มีคนเข้ามาใช้จำนวนมาก ซึ่ง Config ที่เขาให้มาถือว่าดีแล้ว แต่จะเหมาะกับเราหรือไม่ต้องตรวจสอบดูกันเองนะครับ

ถึงวันนี้ก็เป็นเวลาหลายปีแล้วที่ผมได้มาจับด้านเว็บเป็นอาชีพจริงๆนับย้อนไปตั้งแต่ปี 2 จนมาถึงตอนนี้ปี 2011 ก็เป็นเวลา 5 ปีแล้วที่ได้ทำอาชีพนี้ โดยต้องบอกก่อน ว่าผมไม่เคยได้จับระบบใหญ่ ไม่เคยเจองานที่ Hit Limit ของสถาปัตยกรรม จนกระทั่งมาทำงานๆหนึ่งที่เรียกว่า “บอทเว็บ” แน่นอน OBVOC ไม่ใช่งานบอทเว็บ ตัวแรกของผม แล้วแต่ละตัวก็ไม่เคยเจอ Limit จนกระทั่งเอามาใช้งานจริง ทำแบบ Commercial จริงๆ แล้วทำให้รู้ว่าจริงๆ สิ่งที่เราคิดว่าดีตอนแรกมันอาจไม่ดีถึงตอนหลังก็ได้ เลยอยากจะมาถ่ายทอดความรู้กับนักพัฒนาหรือใครก็ตามที่ กำลังจะทำเว็บขนาดใหญ่หรือมี Transaction สูงๆแล้วก็เป็นสาเหตุว่าทำไมผมถึงต้องพัฒนาก้าวไปอีกขั้นด้วยเทคโนโลยีที่พึงมาในปัจจุบัน โดยสาเหตุที่เจอมากับตัวก็คือ

1. เงินทุนที่่มีอย่างจำกัดทำให้เรามี Server ขนาดเล็กกว่าที่ Application เราต้องการสมมุติว่าคุณมี RAM อยู่ 1GB แล้วเป็น Shared CPU แต่คุณต้องการทำ Fulltext , การวิเคราะห์และคำนวณเพื่อนำมาทำสถิติ ซึ่งใช้ CPU 100% เกือบตลอดเวลา ดังนั้นปัญหาแรกคือ “ทรัพยากร” อย่ามีน้อยเกินไปกับขนาดตัว App แต่อย่่างว่าใครจะไปรู้ต้องลองทำๆไปแล้วเดียวถึงจะรู้เอง
2. ทดลองกับข้อมูลจำนวนมากๆ ปกติแล้วเราทำเว็บไซต์จะทำกับข้อมูลจำนวนน้อยๆก่อน แล้วสิ่งที่คุณจะเจอปัญหาก็คือ เมื่อมันถึงจุดๆหนึ่งที่ RAM ไม่พอพักข้อมูลของคุณใน MySQL (Database) อื่นๆระบบคุณจะช้าขึ้นไม่ต่ำกว่า 5x-20x ทำให้จากเว็บดีๆของคุณช้าในทันที โดยผมบอกได้เลยว่าปัญหานี้ไม่จำเป็นต้องทำตั้งแต่เริ่ม แต่สิ่งที่ควรทำคือหาเลขนี้ให้ได้ “อัตราการโตของข้้อมูลจริงต่อวัน” ให้เก็บข้อมูลสัก 30 วันคุณจะรู้อยู่่สองเลขก็็คือ Database โตขึ้นต่อวันเท่าไร และค่าเฉลี่ยต่อ 30 วันเท่าไร แล้วให้คุณไปหาอีกเลขหนึ่งที่สำคัญก็คือ “ฐานข้อมูลโตจากวันแรกจนถึงวันที่  30 คิดเป็นกี่ %” แล้วลองทำนายดูว่าอีก 90 วันข้างหน้ามันจะมีข้อมูลเท่าไร ซึ่งแบบนี้คือวิธีคิดง่ายๆ เรื่องจริงมันไม่ง่ายที่จะเดาแบบนี้เพราะมีเรื่อง Marketing มาเกี่ยวข้องด้วย
3. พอเราหาอัตราการโตข้อมูลเจอแล้ว สิ่งที่คุณควรจะทำต่อไปก็คือ “ทดลองด้วยจำนวนข้อมูลที่ทำนายไว้อีก 90 วันหรือมากกว่านั้น” โดยถ้ามั่นใจแล้วว่า Feature ไม่เปลี่ยนแปลง ผมขอแนะนำว่าให้ทดสอบแบบ Stress Test หรือทำให้สุดไปเลยคือ Insert ข้อมูลเข้าไปเรื่อยๆแล้วลอง Test ระบบว่าระบบเราเริ่มช้า ให้จดเลขนั้นไว้ไม่ว่าจะเป็นจำนวน Record หรือ Database Size แล้วลองนำกลับมาคำนวณดูโดยใช้เลขเดิมที่เรามีโดยคราวนี้เราจะหาว่า “จะใช้ระยะเวลาเท่าไรถึงจะถึงข้อมูลจำนวนที่ทำให้ช้า” โดยวิธีก็คือ ให้เอา      จำนวนข้อมูลที่ทำให้ช้า / อัตราการโตข้อมูลจริงเฉลี่ยต่อวัน  โดยถ้าอยากให้แม่นกว่าเดิมให้เอาอัตราการเติบโต (%) ไปหารอีกทีก็จะได้ข้อมูลแบบหยาบๆมาพอดูได้ว่า อีกกี่วันถึงเวลาที่เราต้องเปลี่ยนแปลงวิธีคิดกับการเข้าถึงฐานข้อมูล ถ้ามันเป็นเวลานานเป็นปีแล้วละก็ชั่งมันไปก่อนไม่ต้องทำอะไร แต่ให้รับรู้ไว้้แล้วจดว่ามันจะช้าเมื่อไร
4. เว็บไซต์มีหลายด้านแต่ด้านไหนจะสำคัญกว่าใครขึ้นอยู่กับแต่ละ Application โดยตัวแปรสำคัญที่ผมคิดว่าสำคัญจริงๆ ก็คือ CPU , RAM , อัตราความเร็วนในการเขียนข้อมูล , อัตราความเร็วในการอ่านข้อมูล , Bandwidth ขาเข้า-ขาออก , Webserver request per sec , Network Latency (ผมใช้ Firebug ดู)
5. เรื่องการทำ Fulltext Search กับ Reverse Index เนื่องจากผมต้องมีการทำการค้นหาข้อมูล เหล่านี้จากบอทที่เก็บมาได้ก็ผมข้อเท็จจริงหลายอย่างว่า การทำ Reverse Index นั้น sure กว่าเยอะว่าจะค้้นหาเจอ แต่มีข้อเสียคือเราไม่รู้ว่าเขาจะหาด้วยคำอะไร จนกว่าจะมีการใส่ข้อมูลเข้ามา ซึ่งถ้าให้ระบบไปทำ Reverse Index ทันที ณ ตอนนั้นก็คงช้า ดังนั้นคุณต้อง Weight เอาดังนี้
   • Like นั้นช้า แต่ข้อมูลที่อยากจะหานั้นตรงกับความต้องการมากกว่า เมื่อข้อมูลมีมากๆนั้นวิธีนี้จะช้าขั้นเทพก็ว่าได้
   • Fulltext Search โดยเท่าที่ผมใช้มา มันค่อนข้างได้ผลประมาณ 70-80% เลยทีเดียวสำหรับภาษาไทย (ผมใช้ MySQL MyISAM fulltext) แต่อย่างว่า ถ้าอีก 20% นั้นเป็นสิ่งที่ลูกค้าผมต้องการหา แต่ดันหาไม่เจอเขาจะพอใจรึเปล่า ? ดังนั้นวิธีนี้คือ Speed มาก่อน , Coverage 70-80% แล้วจะช้าเมื่อเริ่มมี Complex Search เช่น ค้นหาข้อมูลที่มีคำว่า “โดม” หรือ “วโรดม” หรือ “ทศนิยม” หรือ “อื่นๆ” และไม่มีคำว่า “ทดสอบ” แบบนี้เป็นต้น
   • Reverse Index ข้อเสียคือไม่สามารถทำให้ค้นหาทันทีได้หรือจะต้องทำ Index ด้วยตัวเองก่อนนั้นเอง วิธีนี้ก็ใช้ Server Side Script ช่วยอย่่าง PHP เอาข้อมูลที่มีมาวิเคราะห์ว่ามี “คำนี้” ไหมเสร็จแล้ว Save ความสัมพันธ์ระหว่างข้อความกับ Keyword ถ้ามีคนค้นหาด้วย Keyword นั้นพอดีคราวหลังก็จะดึงข้อมูลขึ้นมาได้แล้ว แต่ข้อเสียมีเยอะมากคือถ้าจะทำ Complex Search นั้นเราจะต้องทำตัว Translate จาก Search Query มาเป็น SQL Query ซึ่่งเสียเวลา
   • Fulltext ผสม Reverse Index วิธีนี้ได้ผลดีที่สุด โดยใช้วิธีการ Union Query กันผลที่ได้คือมีความถูกต้องสูง สามารถค้นหาได้ทันที แต่ก็ไปตายที่ Complex Search อยู่ดี
6. ควรจะรู้จัก CAP Theorem ซึ่งเป็นหัวใจที่ต้องเลือกว่าจริงๆ แล้วระบบเราต้องการแบบไหน ซึ่งตรงส่วนนี้ถ้ามีประสบการณ์จะเข้าใจความสำคัญในการเลือก CAP โดยทำให้เราก้าวไปเป็น Web Developer อีกขั้นหนึ่งโดยจะเข้าใจคำว่า “one size doesn’t fit all”
7. อย่ามองข้าม Script Automation และ Alert สองเรื่องนี้ถือว่าเป็นสิ่งที่ทำให้ชีวิตของคนเขียน Program สบายและมีความสุขได้ ถ้าขาดส่วนนี้ไปงานจะเยอะขึ้นเรื่อยๆ จนเราปวดหัวเลยทีเดียว โดย Automation ให้ได้มากที่สุดเท่าที่เราทำได้ ทั้ง Log ข้อมูล , Backup ข้อมูล , Process ข้อมูล ฯลฯ เท่าที่คอมพิวเตอร์จะทำได้ ผมมั่นใจว่าถ้าการเขียนครั้งหนึ่งสามารถแก้ปัญหาหนึ่ง ที่คุณต้องใช้เวลา 10 นาที – 30 นาทีทำต่อครั้งนั้นถือว่าคุ้มค่ามากเพราะ มันคงไม่เกิดเพียงแค่ครั้งเดียวเป็นแน่แท้ ! แล้วคุณก็เอาไปใช้กับระบบอื่นได้อีกด้วย อีกอันที่สำคัญคือระบบ Alert คุณเบื่อไหมที่ต้องค่อย Monitor อะไรบ้างอย่างบ่อยๆทั้งๆที่เรื่องมันไม่ได้เกิดตลอดเวลา เช่น ระบบกำลังจะ Memory หมด , CPU หมด , มี Process บางตัวใช้ CPU เกิน 80% แล้ว Log ฯลฯ ซึ่งเรื่องราวนี้ขึ้นอยู่กับว่าคุณต้องการให้มันเป็น Automation หรือ Alert
8. Backup Backup Backup โดย Backup ที่ว่านี้คืออย่า Backup เฉพาะในเครื่องเดียวกัน ให้มีการกระจายข้อมูลไปที่อื่นด้วย หรือนำมาเก็บไว้ในเครื่องตัวเอง เพราะข้อมูลเป็นสิ่งสำคัญที่สุดของเว็บถ้ามันหายไป เว็บเราก็คงเหมือนเริ่มใหม่กันเลย ดังนั้นอย่าลืม Backup ไม่ว่าจะด้วยวิธีการไหน แต่ผมแนะนำ Incremental Backup แต่ถ้ามันทำได้ยาก ก็แนะนำว่า Backup ทั้งหมดไปเถอะดีกว่าหายครับ

จบแล้ว 8 ข้อโดยจริงๆยังมีอีกมาก แต่เรื่องเหล่านี้เป็นเรื่องที่ผมเจอตอนทำ OBVOC เลยอยากจะนำมา Share ให้ฟังกันครับ

เนื่องจากผมใช้ VPS อยู่แล้วที่นี้ผมมี RAM จำกัดที่ 2GB แต่พอดีผมใช้มันเกือบเต็มแล้วละ ปกติจะ kill process ของ clamd (antivrius) , spamd กับ dovecot ทิ้งเพราะมันกิน Ram เยอะ แต่อยู่ดีมันก็จะกลับมาเฉยเลย เป็นสาเหตุทำให้ระบบผมรวนแล้ว Ram เต็มทำให้ระบบผม ทำงานต่อไม่ได้เลยดังนั้นผมเลยต้องหาวิธีปิดมันแบบถาวร ซึ่งเพื่อนผมก็ประสบปัญหานี้เหมือนกันเลยบอกว่าใช้

NTSYSV

แล้วก็เลือกโปรแกรมที่ต้องการปิดโดยผมมีรูปตัวอย่างให้ดูด้านล่างนี้เลยครับ (กดที่รูปเพื่อดูรูปใหญ่นะครับ)

โดยวิธีควบคุมก็ใช้ เครื่องหมายขึ้น , เครื่องหมายลง ถ้าจะปิดอันไหนใช้ Spacebar ครับส่วนไปที่ OK หรือ Cancel ให้กด Tab ครับ เพียงเท่านี้ ก็ได้ Ram คืนมาแบบไม่ต้องกลัวว่าอยู่ๆมันจะกลับมา แล้วทำให้ Mem คุณหมดไปแล้วครับ