สังเกตุได้ว่าการใส่ Comment ไว้ในข้างหน้าหรือข้างหลัง Query จะทำให้เราบอกได้ว่าจริงๆ Query นี้มาจากที่ไหน โดยถ้าเป็นผมจะตั้ง Comment แบบนี้

/* [OBVOC] application/model/page.php @ function get_by_date */

ประมาณนี้คือ “[ชื่อapp] ชื่อไฟล์ @ function ไหน” หรือถ้าไม่ได้เขียนเป็น function หรือใน function มีการทำหลาย query ก็ใส่ (1) , (2) , (3) ไปก็น่าจะ ok แล้วผมว่าใครมีวิธีการ comment แบบไหนให้หาได้ง่ายก็มา share กันนะครับ โดยสรุปข้อดีในการ Comment ใน Query คือ

• เวลาทำ DB Performance Tuning ทำให้หาส่วนที่ทำให้เกิด Query ช้านี้ได้ทันทีว่ามาจาก app ไหน
• ทำเป็น Remark ได้ว่า Query นี้จุดประสงค์เอาไว้ทำอะไร
• คนที่มาทำงานต่อสามารถรู้ได้ทันที ว่าถ้าจะแก้ไข Query นี้ต้องไปแก้ที่ไหน

• วิธีใช้เงื่อนไข IF , Sub-Query ฯลฯใน MySQL เพื่อให้ได้ผลลัพธ์ที่ต้องการ
• Software Architecutre , Design , Coding และ Optimize
• ออกแบบ Pantip 3G ในรูปแบบของโดมินิค

• OS : Centos 5 with DirectAdmin
• PHP 5.3.8 , MySQL 5.1
• Server : CPU 8 Core , Ram 16GB , HDD 250GB

ผมโชคดีอย่างหนึ่งที่ได้ Server ใหม่มา ไม่งั้นไม่มีทางทำสำเร็จได้แน่ในคราวนี้ โดยปัจจัยแรกที่สำคัญสำหรับระบบที่ใหญ่ขึ้นคือ “Server” แต่กระนั้น เราจะรู้ได้ไงลองไปอ่าน โพสนี้ดูนะครับ เสร็จแล้วคราวนี้พอมีเครื่องที่พร้อม แต่เชื่อเถอะว่า ถึงแม้มันจะพร้อมแต่บางครั้งคุณก็ไม่สามารถปรับ Performance ให้สุดได้เพราะ Ram นั้นต่อให้มี 128GB ถ้าเรา config มั่วๆก็หมดได้อยู่ดีครับ ลองดู Case ผมเป็นตัวอย่างแล้วกันครับ โดยผมจะบอกเรื่องราวก่อนและหลัง แล้วตอนท้ายไปชม Video กันนะครับ

ก่อนหน้านี้ที่มี OBVOC ตัวเดียว

• มีการอัพเดต Row ที่ขนาด 10kb ขึ้นไปเพราะเป็นการดูดกระทู้ เช่น Pantip , Sanook  เข้าระบบ
• ใช้ MyISAM Fulltext เพราะ Implement ได้ง่ายกว่า Sphinx , Solr แต่ปัญหาคือ Index จำนวนมาก
• ข้อมูลเริ่มเต็ม Table เดียวก็ 16gb แล้ว
• ถึงแม้จะ insert / update บ่อยแต่ก็ยังรับไว้ในเครื่อง ram 3gb
• เวลาจะดู Dashboard ในหน้า OBVOC บางครั้งใช้เวลาถึง 30-60 วินาที

หลังมี OBVOC และ OBHUNTER ร่วมกัน

• Transaction มากกว่าเดิม 3 เท่า
• มีการ Access Disk มากกว่าเดิมมากๆ เพราะ OBHUNTER เป็นการอัพเดตข้อมูลไม่เล็กไม่ใหญ่ แต่ถี่ๆ เช่นตัด comment จาก pantip ออกมา insert
• Table ที่โตวันโตคืนเป็นคู่แข่ง table ของ obvoc ทำให้ไฟล์ใหญ่ขึ้นมาก
• OBHUNTER ได้ใช้สถาปัตยกรรมคล้ายๆกับ OBVOC ก็คือใช้ Fulltext ซึ่งปัญหาคือ Index มันมากๆๆๆ กว่าเดิมเข้าไปอีก
• ระบบทั้งหมดช้าลง แล้วเกิดอาการ Hang เพราะมีการ Access Disk เยอะจนไม่สามารถแม้กระทั่งเข้า FTP/SSH (Write Access 99%)
• บางครั้งต้อง Repair พร้อมกับเปิด Service เพราะกลัวเรื่องข้อมูลเก็บได้ไม่หมดจากบน Social Media

ปัญหาที่เกิดระหว่างการ Tuning

• ลองผิดลองถูก ทำให้บางครั้งการแก้ปัญหาไม่ถูกจุดทำให้ระบบแย่กว่าเดิมต้อง Restart VM กันเลย
• เจอ Bug ที่ประหลาดมากนั้นคือ “Crond” เกิดขึ้นมาเป็นจำนวนมากกว่า > 1000 เคยหลับไปแล้วตื่นขึ้นมา ram 16gb เต็ม งงกันไปเลย
• Table ขนาด 16gb พังแค่กด stop start mysql ! ได้บทเรียนว่าก่อน start stop ควร kill ทุก process ที่เข้ามาใน db ไม่งั้นมีโอกาสพัง confirm !! (โดยพี่ @icez บอกเพิ่มอีกนิดว่าอาจจะเป็น Distro ของผมที่ใช้ Centos with DirectAdmin ทำให้มันรวนได้ง่ายขนาดนี้ ดังนั้นใครลง Distro แนะนำว่าลงเองดีกว่า !! ถ้าคิดการใหญ่)
• การ Repair Table แบบผิดวิธีคือ เข้าใจผิดว่า Repairing by Keycache นั้นเร็วกว่า Repairing by Sorting จริงๆผิดครับ Sorting เร็วกว่า แล้วถ้าจะให้ดีต้องมี Thread ด้วย ดังนั้นก่อน Repair ควรปรับ config key_buffer_size=2048M sort_buffer_size=2048M read_buffer_size 512 แล้วก็ write_buffer_size 512 ไม่งั้นช้ามาก + ผลพวงที่ไม่ทำแบบนี้อาจทำให้เกิด Write Access 99% ทำให้ server พังเดี้ยงได้ อาจะเพิ่มเติมได้ที่ ลิงค์นี้
• ระหว่าง config มั่วๆถ้าไม่ set connection timeout แล้วละก็ ram จะหมดรวดเร็วอย่างไม่รู้ตัว (ของผมหมดเร็วเห็นได้ชัดเพราะบอทมันกระหน่ำเข้ามา) โดยตอนนี้ ผมเลยปรับ config เป็นแบบนี้เลย interactive_timeout=100 , wait_timeout=100 ,connect_timeout=10
• การปรับ Tuning MySQL ไม่ดีดูง่ายๆ ถ้าปิด MySQL แล้วระบบมีการ Write Access เท่าไร แล้วเมื่อเปิด MySQL เท่าไร ถ้าเลขมันมากหลังเปิด MySQL นั้นและชัดเจน !
• ถ้ายังอยากใช้ MySQL ต่อไปต้องเข้าใจ InnoDB กับ MySQL โดยผมเจอปัญหาหนึ่งที่แก้เท่าไรก็ไม่ได้สุดท้ายเลยต้องเปลี่ยน Storage Engine ถึงบรรเท่าปัญหานี้ได้
• low_priority_updates = 1 นี้คือท่าสุดท้าย สำหรับคนใช้ MyISAM ถ้าแก้ปัญหาไม่ได้สักที ลองเปลี่ยน config นี้ดูครับ โดยเป็นการให้ความสำคัญกับ UPDATE SQL น้อยลงครับ โดยปกติแล้ว UPDATE จะสำคัญกว่า SELECT ที่มันน่าเซ็งก็คือ ถ้า UPDATE มาแล้วมี SELECT ตาม UPDATE จะช้าลงครับ (มันคือเรื่องจริงครับลองมาเยอะแล้วสำหรับ MyISAM) โดยถ้าปกติมีอย่างใดอย่างหนึ่งจะเร็วทั้งคู่แต่ถ้ามาพร้อมกันเมื่อไร ช้าเลย Lock ด้วย ผมเลยแก้ปัญหาคือให้ SELECT ไปก่อน เพราะถ้าเรา Tuning ดีแล้ว SELECT จะเร็วปรี๊ดแล้วระบบก็จะได้เอาเวลาไปทำ UPDATE ได้เร็วกว่าเดิม ลองแล้ว confirm ว่าเร็วกว่าให้มันเป็นแบบปกติใน Table MyISAM แต่มีผลเสียคือ “บางครั้ง User กด Update ไปแล้ว แต่มันไม่ได้ทำงานทันที เลยเห็นเป็นข้อมูลเก่าอยู่ๆทั้งที่ส่ง request ไปแล้ว”
• Log คือศัตรูตัวฉกาจสำหรับระบบที่มีการ Insert/Update เยอะๆ เพราะมันคืออีก 1 ตัวที่ทำให้เกิด Write Access ว่ากระนั้นผมเลยปิด Log หมดเลย (แต่ปิดตอนที่เริ่ม Tuning เริ่มดีแล้วนะ ไม่ใช่ปิดแต่เริ่ม) ผมปิดหมดเลยครับทั้ง log-queries-not-using-indexes , log , log-slow-queries , log_error , log_warnings ปิดหมด แต่ตัวที่ห้ามปิดเด็ดขาดคือ log_bin เพราะเจ้านี้สำคัญมากเวลาจะกู้ข้อมูลจากการ Repair ดังนั้นอย่าปิดยอมๆไป
• MySQL.. ERROR! Manager of pid-file quit without updating file. เวลา restart mysql นั้นส่วนใหญ่มาจากเขียน config ซะมากกว่า pid ตัวนั้นค้างอยู่ในระบบ
• Read Buffer Size เป็นตัวเดียวที่ใส่เป็นแค่ 8MB ก็เพียงพอแล้ว ที่เหลือต้องแล้วแต่ระบบ
• การทำ Index เยอะใช่ว่าจะดี เพราะมันคือการเพิ่ม Write Access !!!! ดังนั้นถ้าตัวไหนไม่ค่อยได้ใช้ให้ Remove Index ทิ้งซะ ผมดันสร้างตัวทำ autoindex มันเลยทำ index ให้ทุก field เลยผลที่ได้ช่วงแรกคือเร็ว แต่พอระบบใหญ่ก็เป็นดังที่เห็น >.<’
• หลงผิดเชื่อในค่าตัวเลข ที่ฝรั่งแนะนำว่าอย่าเกินเท่านี้นะ มันจะมีผลต่อ Performance Issue ทำให้เราไม่กล้าปรับ จนสุดท้ายมันก็ต้องปรับ แล้วมันก็ดีขึ้นจริงๆด้วย !!
• กด Repair Table ไปแล้ว Bug Crond มันเกิดขึ้น ไม่มีหน้าจอที่เข้า SSH ไว้สุดท้ายเลยต้องมานั่ง Kill มือเพราะมันเกิดตอนจังหวะ Repair Table ไปแล้ว 3 ชั่วโมง !! + ทำใหม่มาหลายรอบเลยใช้ DirectAdmin ช่วยแล้วก็ใช้ jQuerify ของ Firefox เข้าช่วยโดย login เป็น root แล้วเปิดไปหน้าที่มี crond เยอะๆแล้วพิมพ์ตัวนี้ลงไปใน firebug console “$(“tr td.list:contains(‘crond’)”).each(function(){ $(“input”,$(this).parent()).attr(“checked”,true) });$(“tr td.list2:contains(‘crond’)”).each(function(){ $(“input”,$(this).parent()).attr(“checked”,true) });” เสร็จแล้วคลิก kill แล้วกดลบ
• Optimize Table ทำให้เร็วขึ้นมหาศาลอย่างเห็นได้ชัด แต่ถ้ายัง Tuning ไม่นิ่งก็อย่าพึง Optimize เลยเพราะถ้า Alter หรือ Repair ก็ต้องกดใหม่อยู่ดี

ความโชคดีที่ผมหาความต้องการของระบบผมเจอ

• ระบบผมมีคนใช้แค่ 10-20 คนเท่านั้น ที่เหลือเป็นบอท ทำให้ Max Connection สามารถปรับลดลงได้
• ผมมี Key Size ทั้งหมด 6.8GB โดยผมลองปรับเรื่อยๆจนมาลงตัวที่ 3GB ซึ่งคลอบคลุม 95% ของระบบแล้ว ซึ่งพอแล้วเอา Ram ไปเพิ่มตัวอื่น
• ผมรู้ว่าระบบผมมีการ JOIN และ SORT บ่อยมาก ผมเลยค่อยๆเพิ่มค่า Buffer และ Test จนลงตัว
• Coding บางส่วนมีผลต่อ Performance ของระบบมาก โชคดีที่ผมเขียนมันขึ้นมาเองเลยจำได้ว่าอยู่ส่วนไหน เลยแก้ได้ถูกจุด

บทสรุปของการ Tuning ในครั้งนี้ คือเราต้องคอย Monitor ตัวเลขต่างๆ ค่อยๆปรับทีละนิดละนิด โดยแต่ละครั้งที่จะ stop อย่าลืม kill ตัวที่มันมา access database ก่อน แล้วคอยใช้คำสั่ง top ของ linux ดูด้วยว่า write access ลดลงแล้วหรือยังกับการ insert/update ปริมาณเดิม ถ้าไม่ลดต้องปรับใหม่ โดยอย่าให้มัน Write Access ทุก Core เยอะกว่า 30% (แต่ถ้ามัน 99% ไม่เกินครึ่งหนึ่งของจำนวน CPU core ก็ปล่อยๆมันไปได้) สุดท้ายท้ายสุดก็คืออย่าใช้ทั้ง Server เกิน 60-70% ของ RAM (ต้องลอง run สัก 24 ชั่วโมงด้วย) เพราะถ้าเหลือพื้นที่ RAM ไว้น้อยกว่านี้เมื่อเกิดมี process ตัวใดเกิดขึ้นแล้วกิน ram เราไปจนหมด เราเข้า SSH/FTP แถม Write Access 99% ผลสุดท้ายคือต้องโทรไปบอกทาง Server ว่ากด Restart ที่เครื่องให้หน่อย ทำให้เกิดความล่าช้าในการ Tuning แถมระบบก็ล่มหมดอีกคราวนี้ ไม่คุ้มกันนะ ที่เหลือก่อนไปชม video ด้านล่างกันผมขอพูดคำๆหนึ่งเลยว่า

Tuning ต้องวิเคราะห์และค่อยๆปรับไปทีละนิด ความเชื่อที่เรา Search จาก Internet บางครั้งก็ไม่จริงเสมอไป เราต้องทดลองทำด้วยตัวเอง เพราะปัญหาของเรา บางทีไม่ใช่ปัญหาที่เขาเคยเจอ

ข้อควรจำ : อย่าใช้ RAM เกิน 70% โดยไม่จำเป็น , อย่าให้เกิด Write Access มากๆเป็นเวลานาน

My.cnf ที่ Tuning ในครั้งแรกของ OBVOC
My.cnf ที่ลองใช้ตาม Internet แต่ไม่ได้ผลใน case นี้
My.cnf ตัวสุดท้ายที่ใช้อยู่​ณ ปัจจุบันนี้

• Tuning MySQL : สำรวจตัวเองและเข้าใจตัวแปร
• ประสบการณ์ 8 ข้อที่อยากให้เด็กรุ่นใหม่รู้กับการทำ Web Development
• วิธี Search MySQL ด้วย Fulltext Order By Query เร็วและแรง

• 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 ที่เขาให้มาถือว่าดีแล้ว แต่จะเหมาะกับเราหรือไม่ต้องตรวจสอบดูกันเองนะครับ

• Tuning MySQL : Case Study OBVOC/OBHUNTER
• วิธี Search MySQL ด้วย Fulltext Order By Query เร็วและแรง
• ประสบการณ์ 8 ข้อที่อยากให้เด็กรุ่นใหม่รู้กับการทำ Web Development

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 ให้ฟังกันครับ

• Tuning MySQL : สำรวจตัวเองและเข้าใจตัวแปร
• Tuning MySQL : Case Study OBVOC/OBHUNTER
• Oracle XE 10g [vs] MySQL v5.1.6 สงครามของฟรี !

NTSYSV

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

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

• Monit สิ่งที่คนทำ Server ควรรู้
• เรื่องเล่า Twitter 19/01/2012 – 25/01/2012
• โลกสมัยเก่า vs. โลกสมัยใหม่ ตอนที่ 1

1. เอาไฟล์ Mp3 ลงไปใน iTunes เลยครับ
2. เลือก hilight ไฟล์เพลงที่ต้องการ convert ทั้งหมด โดยใช้ Shift ช่วยครับ
3. เปิดไฟล์ที่ดาวโหลดไปครับ คราวนี้มันจะเปิด script โปรแกรม apple script editor ขึ้นมาครับ
4. กด Run ใน apple script editor เสร็จปุ๊บมันจะขึ้นว่าต้องการ convert ทั้งหมด x ไฟล์ใช่หรือไม่ก็กดใช่ครับ
5. เสร็จแล้วมันจะทำการ run ไปเรื่อย โดยขอแนะนำคือใน 10.6.x รุ่น beta ที่ผมลองดูอยู่นั้นมีปัญหาคือ
   • บางทีจะกด convert ไม่ได้ให้ออก itunes แล้วเข้าใหม่
   • บางที convert ไปกลางคันแล้วขึ้น error เฉยให้ออกแล้วเข้า itunes ใหม่ เสร็จแล้วให้ลอง convert ทีละ 30-80 ไฟล์แทน

สรุปแล้วคือใช้ได้ถึงแม้จะมี Bug บ้างแต่ก็ทำให้แก้ปัญหาของผมได้ ขอขอบคุณคนทำ Script นี้อีกครั้งนะครับ

• วิธีทำ iPad Wi-fi Sync Apps กับ Books บน iOS5 กับ iTunes 10.5 บน Mac
• ลองใช้ Mac OSX Snow Leopard เสือดาวหิมะ
• ย่อรูปลง Facebook ฉบับคนธรรมดาด้วย XnView

http://neetgadget.com/quick-tips/how-to-restore-your-previous-sessions-automatically-on-firefox-4/

สรุปสั้นๆก็คือ

1. ถ้าเป็น Mac ไปที่ Firefox > Preferences > General , ถ้าเป็น Windows เป็น Options > General
2. ตรง When Firefox Start ให้เปลี่ยนเป็น “Show my windows and tabs from last time”
3. กด OK เป็นอันเสร็จครับ

แค่นี้เวลาเราเปิด firefox ทีไรมันจะเปิด session เก่ากลับมาซึ่งทำให้ group tab เรายังอยู่ด้วยครับ

• ลองใช้ Mac OSX Snow Leopard เสือดาวหิมะ
• กำจัด Zita.exe แบบลูกทุ่ง
• Firefox 3 Add-on : Tabs Open Relative

https://graph.facebook.com/?ids=http://www.dominixz.com/blog/review/software/10-iphone-4-apps-that-i-use-episode-1

ลองเอาไปแปะบน Browser ดูครับมันจะ Return มาเป็น Json หน้าที่ของเราคือ ถ้าใน PHP ก็คือ $var = json_decode(file_get_contents(url)); เพียงเท่านี้จะได้ตัวแปรที่มี object share count มาใช้งานแล้วครับผม

• มารู้จัก Facebook Graph API กัน
• PHP เรียกใช้ Web Service ของ .NET ด้วยการส่งและรับ Object
• Blog ชิลๆ Style วันเสาร์อาทิตย์ : Make it for me

http://developers.facebook.com/tools/lint/

ซึ่งเป็น Tools ตรวจสอบหน้า Page ของเราว่าได้ทำงานถูกต้องกับ Facebook  รึยังโดยง่ายๆเพียงใส่ URL เดียวมันก็จะบอกผลมาว่าต้องแก้อย่างไรบ้าง หรือ OK แล้วครับ

• โปรโมตและทำ Marketing Online ง่ายๆสำหรับ SME ตอนที่ 1
• Sodia เครื่องมือโพสข้อความอัตโนมัติบน Facebook Page
• Sodia – Creative Business Case Study

กด Menu > Settings > Wireless & Networks > Mobile networks แล้วกดติกถูกที่ “Data Enabled”

เป็นอันเสร็จพิธีครับผม

• Network Onebitmatter โดยอ.ศุภเดช (@ripmilla)
• Android Wellcom A88 – ตรวจสอบก่อนซื้อ
• การใช้ jQuery Ajax put กับ delete ใน Ruby on Rails